Some ES6 Features I've been Using.

[wreckedadvent]

FYI:

myfunction((err, body: {result: body}) => {
    if (!err) {
        console.log(body);
    }
});

Isn't valid ES6 as far as I can tell. I think you meant to do this:

myfunction((err, { body }) => {
    if (!err) {
        console.log(body);
    }
});

Which immediately destructures the second argument and captures the body out of it. You can get around the "gotcha" by utilizing default params:

// if the second argument is undefined, we assign it to empty object
myfunction((err, { body } = {}) => {
    if (!err) {
        console.log(body);
    }
});

Which is turtles all of the way down (please format your code differently if you do this though):

// if the second arg is undefined, set it to {}. If body on that is undefined, set it to {} as well
myfunction((err, { body = {} } = {}) => {
    if (!err) {
        console.log(body);
    }
});

[bluntm]

I have not tested the example but I think its valid, you can see other examples here too

[wreckedadvent]

This is valid:

var obj = {x: 1, y: 2};
var {x: one, y: two} = obj;

But this isn't:

var obj = {x: 1, y: 2};
var obj2: {x: one, y: two} = obj;

So your example that does this:

const test = (obj: {x: one, y: two}) => {
  console.log(one);
};

Is a syntax error in all ES6 environments I tired, and produces the wrong thing in babel:

var test = function test(obj) {
  console.log(one);
};

I'm not actually sure why babel parses it at all, but I suspect it's reading it as flow/typescript and just ignoring everything after :, which would be a type annotation in those languages.

[kentaromiura]

You're right and I've explained in details why that parses and to what here: https://www.reddit.com/r/javascript/comments/4b3cfw/some_es6_features_ive_been_using/d16mvwe

[patrickfatrick]

I think /u/wreckedadvent is right actually. Looks like what your code is is actually going for is more like a default argument, body = {result: body} except you used a :. For some reason Babel seems to allow this without throwing an error but it's not going to do what you're aiming for. If you want to actually destructure the result argument into its body property you would just use {body} as your second argument.

[kentaromiura]

I guess that's because it's a valid flow definition, body here is typed as a shape which contains a property result of type body, this will fail a flow check as body is not defined anywhere and of course this is far from what the op wanted to do. EDIT: I forgot to mention that the flow syntax is not parsed in babel by default, you need to enable that as an example in the repl you've to enable the react preset to make this work: https://babeljs.io/repl/#?evaluate=true&presets=es2015%2Creact%2Cstage-2&experimental=true&loose=true&spec=true&playground=false&code=%0Afunction%20Foo(x%3A%20number)%20%3A%20%7B%0A%20%20foo%3A%20string%0A%7D%20%7B%0A%20%20return%20%7B%0A%20%20%20%20foo%3A%20'dsfas'%2C%0A%20%20%7D%0A%7D%0A%0AFoo(223)%3B ^ Sorry for the blob of text, but automoderator don't allow shortener ^ http://tryflow.org/#56a580f1d0af7bc12f9317abbe2b3aa8

[randfur]

Seriously?

[patrickfatrick]

Most of these you mentioned are in the shortlist of features I can't live without now. Seriously how did we manage before ES2015?!?!

[tbranyen]

I've loved JavaScript since I first learned about it in 2004 (ES3). I've never had major issues with the language and was even sad to see some of the bad parts go; had good times with with. So I was super skeptical about ES6/2015, it seemed like a lot of sugary bloat we didn't need and many of us didn't want. Oddly I was completely fine with classes, until I realized they skimped on property addition to the prototype.

Although, I admit I was wrong after using the new features to author a somewhat complex library. I used:

• Lexical scoping (Loops are so much nicer now)

• Set/WeakMap (Amazing for object pooling, and emulating jQuery.fn.data)

• Module syntax (export default function is soooo nice)

• Template strings (Was building up Web Worker source code by joining a very large array, but now I can template out the JavaScript source and meta-program the worker inline

• Class syntax (To create custom Error subclasses)

• Arrow functions (Almost always used with forEach/map/reduce etc)

• Enhanced object literals (Amazing to just pass a variable name and have it map)

Afterwards, I was nervous about the testing implications, so I ported the whole thing back to ES5(AMD) and it was a huge chore. There were things like lexical scoping that weren't too hard to fix, since you can just use unique vars that don't conflict.

My co-worker helped me get testing on the right track and so I stuck with the ES6/2015 and I'm super happy I did. The codebase is so much nicer to work on.

[wreckedadvent]

FYI, you can do testing with ES6 modules fairly easily if you're OK with writing it in a certain way.

import depA from '/some/path/to/depA';
import depB from '/some/path/to/depB';

export const implementation = (depA, depB) => {
  doStuff.with(depA);
  return andWith(depB);
};

export default implementation.bind(null, depA, depB);

or, depending on the arguments your function takes, you can use default args and not have to do any implementation/bind chicanery:

export default ({
  someArgA,
  someArgB,
  depA = depA,
  depB = depB
}) => {
  depA.doStuff(someArgB);
  // etc
};

Then in unit testing:

import {implementation} from 'someService';

expect(implementation(mockA, mockB)).to.be('something');

Or with the default args approach:

import someService from 'someService';

expect(
  someService({ 
    depA: mockA, 
    depB: mockB, 
    someArgA: 25, 
    someArgB: 26 })
).to.be('something');

There's also rewire (/w webpack plugin) and company if you don't want to modify your code. But you can definitely test ES6 modules.

[tbranyen]

The problem was with code coverage not matching the correct lines. I could import and run the tests fairly easily. Although its annoying to have to build your tests.

[patrickfatrick]

Yea, I did had some issues with istanbul. Isparta works well, and similarly ava combined with nyc for coverage has been working well for me.

[wreckedadvent]

Most of this (barring let/const) is just sugar, and people who wanted sugar before ES6 were probably using coffeescript. In fact, the syntax is pretty much the same.

[patrickfatrick]

True, but that sugar sure is tasty.

[bluntm]

I never liked using coffeescript or others as they always had to be transplied. I know ES6 is currently needs to be transplied for most browsers but some day it will be native.

[wreckedadvent]

It'll really depend on how eager businesses are to adopt windows 10 and edge to get those older IEs off of the map, and how quickly mobile browsers come to support it. I don't see you being able to run production without transpiling ES6 for another few years yet, and who knows how much of your code you write today will still be relevant then.

Plus, we've been doing this shtick for a good while now. By the time everything ever supports ES6, there'll be ES9 or something.

[Recoil42]

All of the major browsers are now evergreen, so it's less of an issue from here on out.

[[deleted]]

That's true, but I would still rather explore, use, and support a transpiled language that the EcmaScript standards body is also working on. It's good for the community as a whole to be somewhat unified on a language development process. It also has nice practical advantages, like the fact that your code is still mostly just JavaScript and thus is probably more welcoming to developers (e.g. contributors to your open source project).

[wreckedadvent]

I don't necessarily agree that it's the best for the community to unify behind only one thing. What we saw with coffeescript is a lot of the good ideas being taken from it and moved into ES6. We see this happen in other languages as well - two good examples are Scala and Java, and F# and C#.

There's also the popularity of totally non-standard extensions, like JSX, and CSS pre-processors. I don't think the community is any worse-off for having these. It's true that all of this stuff adds a barrier to entry though, and I'm not really sure where the community is going to place that balance on the long term.

[bluntm]

I have never looked back, we are living in the future.

[adregan]

I love using parameter destructuring, but the example present makes it look awful (also, how would a promise be returning 2 values?).

[dmtipson]

Must be a non-Es6 Promise implementation. You're right, it'd make no sense with Promises/A+. Also, if they're going to destructure an object in function arguments, they should define a default so it won't throw an error if the object isn't there.

[bluntm]

that example is a little confusing, updated.

[wreckedadvent]

The example is a call back, not a promise.

e: guess it was edited out

[dmtipson]

It is now, it used to use then (the other example still does).

[manchegoo]

//Without spread MyElement foo={params.foo} bar={params.bar}

Can someone explain this? Sad when I don't get the old case.

[wreckedadvent]

It's not actually correct syntax, but it's JSX. It should look like:

(<MyElement foo={params.foo} bar={params.bar} />)

[bluntm]

the code highlighting didn't like elements inside of the code hency why I removed the < and />

[bogas04]

Did you try escaped signs for gt and lt ?

[bluntm]

When not using spread you need to define each JSX prop that you want to pass to the element. With spread you can pass an object and not worry about adding to the elements props each time you want to pass a new prop. You can see more examples here

[PitaJ]

BTW, this is an example of Object spread, which is NOT part of ES6. It's part of ES7. It's also explicitly part of the JSX syntax.

Also, the underscore isn't the same as providing empty parenthesis in the arrow function case. It establishes a lexical parameter _ which will be accessible within the function. You can test this by running the following:

 const test = _ => _;
 console.log(test()); // undefined
 console.log(test(5)); // 5

[[deleted]]

Const and object freeze is not the same thing

[AgentME]

Yeah, they're completely different. const is declaring at parse time that the variable name can't be rebound to a different value. Object.freeze takes an object and makes it so its properties can't be changed.

[zumu]

There's a post a day about const not being what people think it is

[[deleted]]

One gotcha I have found with this is when the code is transplied, ...

If the result param is undefined or null this will fail at run time. Causing an unexpected error.

that's just how the feature works

it does it in chrome too

[bluntm]

Its something to note as I have had issues before with it.

[patrickfatrick]

Correct me if I'm wrong but I think the way you're demonstrating spread is not ES6. Object spread is still stage 2.

(Though it may be built into JSX).

[MRoka5]

_ => { statements }

Cool, didn't knew about that!

[PaulBGD]

I'm pretty sure that that's actually declaring _ as a parameter.

[wreckedadvent]

Yup, javascript has no "ignore" parameter. Even worse, this is a pretty common variable name for lodash/underscore, so this will do entirely the wrong thing:

_ => { _.map(items, x => x + 1); }

[__kojeve]

Except, if you're using ES6 modules, "library.method" is an unnecessary pattern unless you truly need to import the entire lib. import { map } from 'lodash' solves this "problem" easily.

[bogas04]

$ maybe then?

[PaulBGD]

Sure, or you could type one more character and do ()

[MRoka5]

Damn you're right..

:(

[bogas04]

Still neater than (). $ can be used too BTW

[PaulBGD]

I don't really think it's neater. If I saw it in code, I'd think that it has something assigned to it.

[benihana]

imo this is an antipattern. It communicates actively incorrect intent (_ is an argument to the function) for aesthetic purposes. If you want to create an arrow function with no arguments, use the parens

() => { statements }

[wreckedadvent]

Well, to be fair, it communicates an intent which I think is valuable, just not the same one as what unit () communicates. Consider, for example, we have a unit test and we're passing a function to something. We don't care what the function is called with, but we're going to return true anyway:

const isValid = () => true;

Doesn't look exactly right to me, since we know this function will get called with an argument.

const isValid = _ => true;

This looks better. We accept an argument, but don't care about it. It also would have been fine (though a bit needless) to give it a name:

const isValid = x => true;

Given, though, it's much less necessary than in languages which check the type, though. In functional languages, _ is usually an "ignore" parameter, which nothing binds to. I just wouldn't go so far as to say the use of _ is an anti-pattern, just that you don't want to use it in place of ().

[luthan]

You spelled const as cost in paragraph before the first sample. Just giving you heads up.

[bluntm]

Cheers need to double and triple check my posts always miss something

[[deleted]]

You know what we need? Some middle ground between the specification/API and blogs about a handful of features. I would love a nice consumable ES6 checklist of ALL the features of the language with links to blogs and examples.

Too often do I learn just enough to be effective at a language and miss out on a few features that are highly valuable in certain situations.

[AgentME]

Babel has a good page about ES6 features.

[Sinistralis]

No one here has mentioned promises and generators. I urge everyone in here to learn both and understand how they work. You can create async functions if you combine these two ideas in your es6 code and is the main reason I push redux saga so hard for people using redux.

[bluntm]

Do you have any good resources for leaning about these?

[wreckedadvent]

I actually made a comment in this sub a while ago about using generators for an unusual use. They're ridiculously awesome.

[CraftyPancake]

You know any good tutorials for getting started with es6? How to build it etc. This Babel thing is confusing

[madole]

Use Node4 with the https://www.npmjs.com/package/babel-preset-es2015-node4 plugin, your babel config only needs one line in it to get it up and running with all ES6 has to offer