TFA's example doesn't work for server-side fetching, and kind of dismisses the issue... the reality is that one should use methods that work for both, if you're going to have universal rendering, so you don't have weird complicated code to do the same thing in two places.
Two things I always try to enforce in code reviews are the use of map/reduce instead of for-loops when practical, and returning early from functions...
// instead of
fn() {
if (foo) {
//really long code block
} else {
//really short code block
}
}
// this
fn() {
if (!foo) {
// really short code block
return ...;
}
// less nested code case
}
It tends to happen a lot, and the function becomes much more clear when you can get out of it asap instead of deep nested blocks.
Interesting, though would be nice if it were a keyboard character used... it always irks me when frameworks choose an obscure character for things like this.
Glad to see extensible end points for webpack, babel (pending) will also be pretty nice. It's a minor niggle, because there are an ever decreasing number of features outside stage-3 that I'm using.
Very nice deck outlining some performance improvements for recent v8 versions... will really be nice to see node@8 with all the new shiny features... async/await is about the last thing I'm using babel for on the server side.
Two things I always try to enforce in code reviews are the use of map/reduce instead of for-loops when practical, and returning early from functions... // instead of fn() { if (foo) { //really long code block } else { //really short code block } } // this fn() { if (!foo) { // really short code block return ...; } // less nested code case } It tends to happen a lot, and the function becomes much more clear when you can get out of it asap instead of deep nested blocks.