Idiomatic ES6: полное руководство

There are a billion articles on ES6 at this point. What’s one more? Here we discuss some emerging patterns and issues related to real world use of ES6 as well as how one can go about using it now via Babel. If you aren’t yet familiar with the features and changes of ES6 itself, you’ll probably want to check out the following links first:

• MDN is invaluable. It provides systematic coverage of all JS, including ES6.
• ②ality isn’t organized like MDN, but it boasts the finest collection of deep articles covering specific features and edge cases.
• The online Babel REPL. This is fantastically useful to answer quick questions like ‘does this work?’ and of course, ‘how?’
• The final draft. Dry reading, but sometimes it’s the only way to get an authoritative answer. Edifying if you stare at it long enough.

  Original author: Darien Maillet Valentine

TABLE OF CONTENTS

• ES6
  • Where We’re At
  • Age of Babel
  • Language Shapes Usage
• Variable Declaration
• Lexical Scope, Blocks, and the End of the IIFE
• Arrow As Default
• Classes, Symbols and Object Literals
• Function Signatures and Binding Patterns
• Iteration
• ES7
  • Holy Grail: Async / Await
  • The Binding Operator’s Questions
• Using ES6 Now

Where We’re At

In April, the ES6 spec reached its final draft. Later this month, the Grand Council of Javascript Elders will shuffle into the silver sanctum to seal the document with unicorn wax. A glass bell will ring in the spire of the tallest tower in the City and leprechauns will be dispatched to carry the good news to the farthest corners of the Kingdom. ‘ES5 is dead, long live ES6!’ they shout.

Unfortunately, that last part takes about ten years. Leprechauns aren’t nearly as fast as Hollywood has led you to believe, and they’re easily distracted.

On one hand, progress towards ES6 support in browsers has been rapid. If you’ve followed the Kangax Table for the last few months, that should be clear. Yeah, there’s a lot of red yet, but look at Firefox 40 (66%), Chrome 45 (45%) and holy s– yes, that really is IE Edge, aka Project Spartan, at 63%. ‘Imagine there’s no heaven…’

• Note, these figures sometimes go down, too, as new tests are added to confirm implementation details. You can only precisely compare them at a given moment rather than over time.

On the other, we’ve all had too many workyears / firstborn stolen by spiteful, undying IE versions to place much stock in the idea that there’s a corner we’ll turn when suddenly it’s totally cool to destructure an array in the browser. Well, you can polyfill Map, you can polyfill Array.from or whatever. But how do you polyfill syntax? ES6 isn’t valid ES5 at a syntactic level. This is a new problem.

Age of Babel

You can’t polyfill syntax – you can transpile it though. Babel has been tearing it up since the tail end of its days as ‘6to5’ (when somebody must have realized it was too npm-big to not have a sexy name). Transpiling JS wasn’t new (in fact we owe a lot of ES6 refinements to Coffeescript), nor was transpiling ES6 to ES5 (Traceur’s been around a while). But npm download stats present a picture of Babel as now being the community’s go-to ES6 transpiler. The line keeps angling upwards.

Babel might owe its popularity to good timing or the fact that they’ve hung onto the highest ‘Kangax Index’ for a while. But that line probably owes its recent incline mostly to the fact that ES6 has been finalized. Suddenly it seems a lot less speculative to jump on board.

Now, many folks feel transpiling is icky:

1. Tougher to debug
2. Feels funny

But that said, some of those who were uneasy about Coffeescript seem to have fewer reservations about writing code that, in theory, won’t need to be transpiled… someday. That may help with #2 anyway – but as for #1, even with sourcemaps, there’s no denying that you’re risking an extra maintenance burden by depending on a transpiler. Is it worth it?

Language Shapes Usage

The answer comes down to the ways ES6 could improve the quality of your code. An enumeration of new features / toys may not help much in determining that because the real-world implications of those features aren’t always immediately clear. It’s through use that we develop a shared vocabulary, composed not by the language’s grammar dictates but by the patterns and preferences – the idiom – that makes it easier for us to work together and write reusable code. A language’s features and syntax do shape the development of that idiom, and language designers take that into account: they’re planting seeds. The available features and syntax will encourage or discourage particular habits and solutions.

At this point, a hazy image of how ES6 really gets used has begun to form. I’ve cataloged a handful of patterns I’ve seen emerging in the wild, tried to supply their rationales (as I see them), and supplemented these with some of the conclusions I’ve arrived at from working mainly in ES6 for a few months myself. As always: YMMV.

Variable Declaration

When first encountering let and const, a common reaction is to think of let as the new var – in fact, I’ve even seen an article called ‘Let Is The New Var.’ The phrase shows up verbatim all over. But it isn’t true: const is the new var.

Alright, that’s not the truth, either. If we’re talking about which is closer in behavior to var, indeed, that’s let. Assuming your code isn’t relying on hoisting and you don’t declare variables in blocks, you could even switch them 1:1 and things would be fine, but that wouldn’t be true with const.

• You may wonder: Where does var it fit in? It doesn’t. It’s sort of de facto deprecated – like with was for years before they made it official. Hoisting was a language design error, and the benefits of lexical scope are the lure being used to guide us out of this particular problem zone.

The gut feeling for those of us used to var is that ‘vars’ are variables and ‘constants’ are … not. True. But we never had constants, so we used (unsightly but distinctive) case conventions when we wanted to communicate that a particular identifier represented a “pre-supplied” value. It could be an enum value, a “plug in your string here to configure this” slot, etc. To Javascript devs, a ‘constant’ was just a variable whose value was somehow hardcoded.

But the real ES const has nothing to do with ‘hardcodedness’. It just means that a binding is permanent for the duration of the scope in which it was declared. Go open some JS you wrote and review it, looking at variables. How many are ever redefined after they’re declared? And (here’s the crux) – of those which aren’t ever redefined, for how many would such a redefinition, were it to be accidentally introduced, constitute an error? Right now that code doesn’t say so. If it happens, there’s no way to directly trace the problem back to a constraint that was never expressed.

With const, that code will be invalid if a redefinition occurs. The mistake would even be detected by static analysis, so you’ll be told exactly where the offense occurred before the code even has a chance to run.

So a simple pattern has appeared in real-world ES6, the logical consequence of these facts: use const except when let is expressly needed. It’s a kind of defensive coding, which is something we don’t see a lot of in fast and loose JS (or, as the Java dev behind me would say, ‘sloppy and inferior’). Fortunately it’s a simple habit to pick up and it yields immediate benefits.

I suppose I should acknowledge that it’s five characters. And that it therefore will not neatly align with four-space tabs. Once you’ve typed it that first time, it gets easier. I promise.

Lexical Scope, Blocks, and the End of the IIFE

Above we addressed lexical scope briefly. The largest idiomatic impact of lexical scope is that it makes an older idiomatic usage more or less obsolete: the IIFE.

The purpose of an IIFE (immediately-invoked function expression) was to provide a scope-for-hire. Before ES6, aside from a few odd edge cases, function scope was the only scope other than global. Node modules might be argued to afford a different kind of scope, but even the hidden innards of that system involve wrapping modules in IIFEs.

Some background if this is an unfamiliar term: there are function declarations and there are function expressions. A function declaration (hoisted, like var) is a type of statement. Expressions can be statements, but not the other way around. Any statement beginning with function will be a function statement, so it can’t be anonymous and it can’t be invoked in place. Since the object is to avoid polluting the current scope, you need to somehow ‘expressionize’ the function. There are a variety of approaches to this. The most common is to parenthesize it; then it is a function expression inside a parenthesized expression, altogether being an expression statement. Other common choices are prefixing with the logical not operator ! (semantically abusive, aesthetically appealing) or the void operator (arguably more expressive, but relatively obscure).

The fact that there’s no consensus about how to do this tells us a bit about IIFEs. The pattern is unavoidable, but it isn’t really ‘acknowledged’ by the language itself. And although we’re accustomed to it, creating these functions, anonymous or not, is an indirect, unexpressive means to get some scope ‘real estate.’ They’re functions in name but not in, uh, spirit.

So in ES6, (function() { /*...*/ })(); becomes { /* ... */ }. Praise.

• Block statements are familiar because we use them routinely as the ‘statement’ part of control and loop statements like ‘for’ and ‘if’, but it’s easy to forget they are a type of statement in their own right. This is why a line starting `{` begins a statement, not an object literal.

Perhaps this means that we’ll see a return of the long-maligned (but harmless) statement label. A block statement (unless it belongs to a loop) can only use break with a label. I haven’t actually seen this as a pattern in practice – just speculating.

A discussion of real usage should address common errors, too. As far as lexical scope goes, there’s one I’ve seen a few times now. Sometimes people who follow the const-unless-let principle abandon it as soon as they get to for/of loops, apparently thinking the identifiers in the loop will be ‘reused’ and are therefore let vars. This isn’t the case – for/of|in loop scopes

1. are unique per iteration and
2. include their initializers! Thus,

for (const char of str) console.log(char); is valid and, if char should be immutable (per-iteration), preferred. Note that that isn’t true of the for ;; loop, however.

Arrow As Default

Here’s a snippet from a developer issue thread for V8. The title of the issue is ‘Implement arrow functions’ and it dates from 2013, which is around 1838 AD in Javascript years:

• What’s wrong with the actual language construct? What benefit does it have to be able to write foo(x => x + 1); instead of foo(function(x) { return x + 1; });, other than saving a few bytes and losing verbosity (i.e. clarity) in the code?

The writer sort of had a good point. It just wasn’t obvious to most folks what arrows were supposed to bring to the table. And they looked weird, which is what he or she is actually saying there. At this point, we’re used to seeing them, and the argument now seems comically backwards (wait, which one has greater clarity?). But at the time, I’d have agreed.

Now, I consider arrow functions to be the “default” that one diverges from only as situationally required. I’ll come clean here – the argument for this that I’m about to present is the product of my own experience, not an observed outside trend (which is what I’ve tried to stick to so far). Take it with a grain of salt.

The core behavioral difference between arrow-functions (AF) and function-functions (FF) concerns this. Many JS devs avoid using this because it’s a pain. It was a pain – arrows fixed it.

Their utility as event handlers is pretty obvious – but it doesn’t say much about why one might treat them as the norm. Well, I’d said that AFs fixed the this problem, but in truth, the choice between AFs and FFs is what’s fixed it. We didn’t just gain a way to express lexical this, we effectively gained a way to express variable this. Afterall, previously we would have used `function` for both, with lexical this approximated with aliases like `self`. Yet in the majority of cases, it simply doesn’t matter: most functions in any given (average) project probably will make use of neither lexical nor variable this.

class SomethingParser extends Writable {
  constructor() {
      super();

      this.on('finish', () => {
          if (this.validate(this.result))
              this.emit('result', this.result);
          else
              this.emit('error', new ParseError('Oh no!'));
      });
  }

  // ...
}

const speak = function() {
  console.log(`I, ${ this.name }, have a variable "this".`);
};

const say = () => console.log(`I don’t. Not really my thing.`);

const $str = Symbol();

class ASCIIString {
  constructor(str='') {
    this.content = str;
  }

  get content() {
    return this[$str];
  }

  set content(str) {
    str = String(str);

    for (const char of str) {
      if (!this.isValidChar(char))
        throw new Error(`Char "${ char }" is not valid.`);

      this[$str] = str;
    }
 }

 isValidChar(char) {
   return char.codePointAt(0) <= 0x7F;
 }
}

class ASCIIStringNoControlChars extends ASCIIString {
  constructor(str) {
    super(str);
  }

  isValidChar(char) {
    return super.isValidChar(char) && char.codePointAt(0) > 0x1F;
  }
}

constructor({ name, age, species='cat' }={}) { ... }

class Me extends Human {
  eat(...args) {
    if (args.some(isJello)) 
      throw up;
    else
      super.eat(...args);
  }
}

const getTagName = str => {
  const [ , tagName ] = str.match(/^<\s*([^\s\/>]+)/) || [];
  return tagName;
};

const refill = ([ dispenser, pez ]) => {

  const [ onePack, ...allTheRest ] = pez;

  dispenser.fill(onePack);

  quietlyEat(allTheRest);
};

Promise.all([ getPezDispenser(), getPez(5) ]).then(refill);

const charCount = str => {
  const register = {};

  for (const char of str) {
    register[char] = (register[char] || 0) + 1;
  }

  return register;
};

const countCharInWord = (word, char) => {
  const { [char]: count=0 } = charCount(word); // wheeeee

  const plural = count != 1;
  const verb   = plural ? 'are' : 'is';
  const suffix = plural ? '’s' : ''; 

  return `There ${ verb } ${ count } ${ char }${ suffix } in ${ word }.`
};

countCharInWord('mississippi', 'i'); // "There are 4 i’s in mississippi."
countCharInWord('mississippi', 'p'); // "There are 2 p’s in mississippi."
countCharInWord('mississippi', 'x'); // "There are 0 x’s in mississippi."

class Stack extends Array {
  /* ... */

  * [Symbol.iterator]() {
    for (let i = this.length - 1; i >= 0; i--) {
      yield this[i];
    }
  }
}

const stack = new Stack();

stack.push(1, 2, 3);

console.log(...stack); // 3 2 1

const $domReady = new Promise(resolve => {
  const state = document.readyState;

  if (state == 'interactive' || state == 'complete')
    resolve();
  else
    window.addEventListener('DOMContentLoaded', resolve);
});

const getXHR = url => {
  const req = new XMLHttpRequest();

  req.open('GET', url);

  return new Promise((resolve, reject) => {
    req.onerror   = () => reject(new Error('Connection failure'));
    req.ontimeout = () => reject(new Error('Connection timeout'));

    req.onreadystatechange = () => {
      if (req.readyState == 4) resolve(req.responseText);
    };

    req.send();
  });
};

const insertPigeon = async () => {
  await $domReady;

  const pigeonHole = document.getElementById('pigeon-hole');
  const pigeonURL  = 'http://www.pigeons.com/carrier.html';

  try {
    pigeonHole.innerHTML = await getXHR(pigeonURL);
  } catch (err) {
    console.error('Unable to retrieve pigeon page :(');
  }
};

insertPigeon();

const { filter, map, reduce } = Array.prototype;

const h1s = document.querySelectorAll('h1')::map(h1 => h1.innerText);

const seconds = function() { return this * 1000; };

3::seconds(); // 3000
'3'::seconds(); // 3000

const toMulti = method => function() { return method(this, ...arguments); };

const round = toMulti(Math.round);

3.5::round(); // 4

const toJSON  = toMulti(JSON.stringify);

({ a: true })::toJSON(); // '{"a":true}'

const forEach = toMulti(_.forEach);

'abc'::forEach(::console.log);
// a 0 abc
// b 1 abc
// c 2 abc

import 'babel/polyfill';
import 'source-map-support/register';

#!/bin/sh

babel \
    --loose "all" \
    --optional "\
es7.asyncFunctions,\
es7.functionBind,\
minification.deadCodeElimination,\
minification.inlineExpressions,\
minification.memberExpressionLiterals,\
minification.propertyLiterals,\
validation.undeclaredVariableCheck" \
    --out-dir .tmp \
    src && \
browserify .tmp/client.js -p bundle-collapser/plugin |
uglifyjs -m -c -- - > lib/client.js && \
rm -r .tmp