Happy New ES2018!
About a week ago, TC39 (ECMA International’s technical committee, responsible for standardizing the ECMAScript language specification) finalized the list of features, which will officially enter ECMAScript 2018. Exciting right? Well, it’s hard to say, since we have no idea what to be excited about yet. So let’s find out, what do they have in store for us!
Rest/Spread Properties
Let’s open with a bang! Arrays are no longer the cool kid in the block, objects are! That’s right, the feature everyone thought was already a part of ES6, since it is supported practically out of the box by everything, including Webpack, TypeScript, Chrome 60 and more, is finally becoming a built-in capability within ES2018. Intuitive as it is, for some reason it wasn’t included in ES6 (or any following edition of the spec for that matter). Okay, enough mumbling let’s see how it works:
The rest operator
const eminem = {firstName: "Marshall", lastName: "Mathers", albums: 9, rapGod: true};
const {firstName, lastName, ...rest} = eminem;let’s log firstName, lastName and rest now:
console.log(firstName); // Marshall
console.log(lastName); // Mathers
console.log(rest); // {albums: 9, rapGod: true}Easy, right?
The spread operator
This one is a handy one. I feel bad for Object.assign (just kidding, I don’t) as the spread operator allows you to assign object properties to another object very easily:
const insect = {ugly: true, annoying: true};
const mosquito = {name: "mosquito", ...insect, friends: Infinity};console.log(mosquito); // {name: "mosquito", ugly: true, annoying: true, friends: Infinity}
Note: All of you JSON.stringify and JSON.parse people beware, the spread operator can be used as a cloning mechanism for shallow clones only. Deep clones as well as true clones (including prototype) cannot be created using the spread operator!
Asynchronous iteration
This is another big one. Asynchronous iterables and iterators are now a thing. Meaning your “next” calls will now return promises, eventually holding an object with the following structure:
{value: 'next iterable value', done: false} // done is true when your iterator finishes cycling through the iterable and doesn't point to anything anymore, i.e: value is undefinedThis is not very easy to understand, so stick with me and I’ll try my best to explain it as clearly as possible using an example.
Let’s say you are a big shot developer with a tight schedule and for some reason you decided to create your own calendar, so you can mark your appointments. Now let’s assume you have an async iterable holding your appointments dates, how would you extract them? Here is a suggestion using ES2018:
const appointmentsIterator = appointments[Symbol.asyncIterator]();
appointmentsIterator.next().then(appointment1 => {
console.log(appointment1); // { value: '11/02/18 11:00:00', done: false }
return appointmentsIterator.next();
})
.then(appointment2 => {
console.log(appointment2); // { value: '12/02/18 15:00:00', done: false }
return appointmentsIterator.next();
})
.then(appointment3 => {
console.log(appointment3); // { value: undefined, done: true }
});Cool cool cool… a million lines of code and promises to get some appointments. Just COOL!
Well you can stay chill, since your next “next” calls (I’m sorry) will be much simpler if you make them inside an async function. Behold:
async function printCalendar(appointments) {
const appointmentsIterator = appointments[Symbol.asyncIterator]();
console.log(await asyncIterator.next()); // { value: '11/02/18 11:00:00', done: false }
console.log(await asyncIterator.next()); // { value: '12/02/18 15:00:00', done: false }
console.log(await asyncIterator.next()); // { value: undefined, done: true }
}If you weren’t mesmerized yet, check out the following:
async function printCalendar(appointments) {
for await (const appointment of appointments) {
console.log(appointment);
}
}
// Prints:
// 11/02/18 11:00:00
// 12/02/18 15:00:00David Copperfield has got nothing on that magic ✨
Promise.prototype.finally()
Finally, The Rock has come back to… sorry wrong finally. But finally promises will have the finally function, which means that whether they succeed or fail, they will always enter the finally call and execute the provided callback.
Let’s see it in action:
logOut()
.then(() => { // promise fulfilled
console.log("Logged out successfully");
}).catch(err => { // promise rejected
console.error("Failed to log out. Details: ", err);
}).finally(() => { // never mind what happened before, this is going to be executed
closeModal();
});I hope we will see even more promise functionality implemented natively in the future (I’m looking at you Promise.try and Promise.allSettled 👀).
Template literal revision
In my opinion the major additions to the spec were already covered by now. It’s not to say that the rest isn’t important, just not as game changing as the previous entries of this list. Starting with the “Template Literal Revision”, which is not a feature per say, more like a limitation drop.
First I need to explain what are tag functions. A tag function is essentially a function name followed by a template literal for an instant application of the function with an object parameter holding the template literal itself. Let’s look at one:
function printFunc(str) {
console.log(str);
}printFunc`It is soccer, not football!`
// {0: "It is soccer, not football!", raw: ["It is soccer, not football!"]}
Now I hear you asking:
Why would I need an object wrapper for my template literal?
I assure you it is a great question. The answer is a bit underwhelming though. So basically this object wrapper is the essence of the tag function. It is comprised of both the cooked and the raw versions of the string. I am smelling the upcoming question in the air so let’s answer it right away.
A cooked string is a string with the escape sequences within it being interpreted, whilst a raw string treats them as regular text. Looking back at our printFunc function, we can clearly see and understand its structure now.
So where is the problem?
As always it lies with the edge cases. Up until now, if you would have used a tag function with a bad escape sequence, you would receive a nasty syntax error. As it is not yet very clear what is considered bad, let’s try the following:
/* GOOD */
printFunct`\u{3A}`
// {0: ":", raw: ["\u3a"]}/* BAD */
printFunc`C:\urawesome\somefile`
// SyntaxError: malformed Unicode character escape sequence
I really think they should have seen it coming, back when template literals were added in ES6. Because now the solution is basically taking a step backwards and removing all syntactic restrictions. In plain english code it means:
printFunc`C:\urawesome\somefile`
// {0: undefined, raw: "C:\urawesome\somefile"}No more escape wars, no more syntax errors, just plain undefined flying all over the place. It is certainly better, but not perfect imho.
Regex Features
Regex is not my cup of tea, which is why I don’t want to elaborate too much and confuse you with my misunderstandings. What I can say though, is that 4 regex related features were added to ES2018, so all of you keyboard smashing fanatics who love unreadable regex ABC mashes, may enjoy an easier life very soon.
Further read
I hope my article was clear enough for you to understand what is coming in the near future. If you would like to learn more about ES2018, I would highly suggest going straight to the source:
I have to admit I was a little disappointed with the absence of some highly requested features such as fields, private members and more, but it is easily fixable in future spec editions. As for ES2018, I’m very excited about the first 3 features I covered. Can’t wait to use them. What about you? What are your thoughts on ES2018? Please share them with me in the comments below! 😃
