(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| document.getElementsByTagName('button')[0].onclick = function () { | |
| scrollTo(document.body, 0, 1250); | |
| } | |
| function scrollTo(element, to, duration) { | |
| var start = element.scrollTop, | |
| change = to - start, | |
| currentTime = 0, | |
| increment = 20; | |
| var gulp = require('gulp'), | |
| debug = require('gulp-debug'), | |
| size = require('gulp-filesize'), | |
| clean = require('gulp-clean'), | |
| coffee = require('gulp-coffee'), | |
| coffeelint = require('gulp-coffeelint'), | |
| gutil = require('gulp-util'), | |
| sass = require('gulp-sass'), | |
| imagemin = require('gulp-imagemin'), | |
| changed = require('gulp-changed'), |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/ is intended for code that can run as-issrc/ is intended for code that needs to be manipulated before it can be usedAll of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParentI really liked @tjvantoll article Handling Failed HTTP Responses With fetch(). The one thing I found annoying with it, though, is that response.statusText always returns the generic error message associated with the error code. Most APIs, however, will generally return some kind of useful, more human friendly message in the body.
Here's a modification that will capture this message. The key is that rather than throwing an error, you just throw the response and then process it in the catch block to extract the message in the body:
fetch("/api/foo")
.then( response => {
if (!response.ok) { throw response }
return response.json() //we only get here if there is no error
})
| function throttle(callback, wait, immediate = false) { | |
| let timeout = null | |
| let initialCall = true | |
| return function() { | |
| const callNow = immediate && initialCall | |
| const next = () => { | |
| callback.apply(this, arguments) | |
| timeout = null | |
| } |
| // | |
| // Smooth scroll-to inspired by: | |
| // http://stackoverflow.com/a/24559613/728480 | |
| // | |
| module.exports = function (scrollTo, scrollDuration) { | |
| // | |
| // Set a default for where we're scrolling to | |
| // |
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.