Is this another overly hyped article about JavaScript. Perhaps!!! Maybe after reading this you will share my enthusiasm 😁. In 2020 JavaScript will be getting some exciting new features. Most of these features are already in the final stage of proposal and scheduled to release in 2020.
Some of these features are already available in the latest version of Chrome and Firefox browsers. So you can start playing with them in your browser right away. If not you can also head over to https://codesandbox.io which is an online ide that allows you to write code in your browser.
If you would like to see all the proposals for new JavaScript features you can find them in the following github link.
⚡️ https://github.com/tc39/proposals
Excited!!!, let’s dive in.
Object.fromEntries()
First on our list is a Object
method. It is very common in javascript to convert objects to array and vice versa. Especially when you are working with database like firebase or some other no-sql service we are often required to do these type of transformation. In es2017 Object.entries()
was introduced which returns an array from an Object
with its own key property.
Let’s take a look at an example.
const object1 = {
foo: "somestring",
bar: 100
};
for (let [key, value] of Object.entries(object1)) {
console.log(`${key}: ${value}`);
}
// Outputs-->
// foo: somestring
// bar: 100
Object.fromEntries
does the opposite of Object.entries
. Given an array it will output an object. Here’s an example
const entries = new Map([
['foo', 'bar'],
['baz', 42]
]);
const obj = Object.fromEntries(entries);
console.log(obj);
// expected output: Object { foo: "bar", baz: 42 }
Dynamic import
This new feature will allow JavaScript to dynamically load modules as needed. Currently when we import modules in JavaScript they are loaded pre-runtime
. This is why we keep them at the top of our files. This works for most cases. However, to increase performance, what if we could dynamically load some of our modules at runtime. This new feature will allow that. Below is an example of dynamic module import.
const main = document.querySelector("main");
for (const link of document.querySelectorAll("nav > a")) {
link.addEventListener("click", e => {
e.preventDefault();
import(`./section-modules/${link.dataset.entryModule}.js`)
.then(module => {
module.loadPageInto(main);
})
.catch(err => {
main.textContent = err.message;
});
});
}
Dynamic imports will allow developers to have greater control in how modules get loaded in application.
- It gives us the power to boost performance by not loading code until it is likely to be used
- It allows to catch error scenarios when application fails to load a non-critical module
- It can ensure modules that are dependent on each other don’t get caught into a race condition
You can read about dynamic imports more in the following GitHub link
⚡️ https://github.com/tc39/proposal-dynamic-import
String.prototype.matchAll()
This method returns an iterator object for all matches in a string. Let’s jump right into an example
const re = /(Dr\. )\w+/g;
const str = 'Dr. Smith and Dr. Anderson';
const matches = str.matchAll(re);
for (const match of matches) {
console.log(match);
}
// outputs:
// => ["Dr. Smith", "Dr. ", index: 0, input: "Dr. Smith and Dr. Anderson", groups: undefined]
// => ["Dr. Anderson", "Dr. ", index: 14, input: "Dr. Smith and Dr. Anderson", groups: undefined]
This method makes it really easy to work with strings, sub-strings and pattern matching with regex.
Promise.allSettled
This one is probably my favourite so far. It does exactly as the name suggests. It keeps track of settle promises. Let’s elaborate this through an example.
Let’s say we have an array of promises. We can execute them with Promise.all
. However, to know their status (which ones resolved and which ones failed) we need to iterate them all and return new value with the status.
function reflect(promise) {
return promise.then(
(v) => {
return { status: 'fulfilled', value: v };
},
(error) => {
return { status: 'rejected', reason: error };
}
);
}
const promises = [ fetch('index.html'), fetch('https://does-not-exist/') ];
const results = await Promise.all(promises.map(reflect));
const successfulPromises = results.filter(p => p.status === 'fulfilled');
As you can see we are passing in a function called reflect
to return the status. The new proposed api will not require this reflect
function. We will be able to do the following
const promises = [ fetch('index.html'), fetch('https://does-not-exist/') ];
const results = await Promise.allSettled(promises);
const successfulPromises = results.filter(p => p.status === 'fulfilled');
Optional Chaining for JavaScript
If you have used Angular or Typescript chances are you are familiar with this feature. We often have to check whether an intermediate node exists in a tree like deep object.
var street = user.address && user.address.street;
The Optional Chaining Operator allows a developer to handle many of those cases without repeating themselves and/or assigning intermediate results in temporary variables:
var street = user.address?.street
var fooValue = myForm.querySelector('input[name=foo]')?.value
Example taken from offcial github proposal page.
Optional chaining can be used in three positions
obj?.prop // optional static property access
obj?.[expr] // optional dynamic property access
func?.(...args) // optional function or method call
Indeed an exciting time for JavaScript. There are a couple of other features that are also up for release in 2020. BigInt
and globalThis
are notable. Hopefully this article was informative, for more articles like this please follow me and hit that like button 🌞 🌞 🌞
Top comments (27)
Optional Chaining is my favorite though.
Not to mention nullish coalescing. 😍
So here's an opinion: none of these are at all interesting as 'features'. They don't really extend the language - at best they're sugar over what's there already. The benefits are minor.
The downsides are not insignificant. Extending the language syntax like this means you have to 'know' a lot more magic symbols and incantations in order to 'know' JavaScript. Every extension like this makes it a harder language to learn with, to my view, very little benefit. "Scheme for the browser" has never looked so complicated.
Nice article though.
If that opinion stands on "lot more magic symbols and incantations in order to 'know' JavaScript" - what does this 'know' means?
Does mastering of JS mean knowing all the features? - I do not think so, there is documentation anyway.
Does mastering of JS mean using all the features? - same answer I guess, no one is using all what is available out there.
"magic symbols and incantations" and "The downsides are not insignificant."? - No, but nice hyperbole. There is documentation, and i cannot think about realistic scenario in which someone knows how to use String.prototype.match() and is unable to get how String.prototype.matchAll() works, or same with Object.entries() and Object.fromEntries() - I think this is just filling holes in something what i would call language 'symmetry' in this case (maybe not so needed, but better to have than to not have :-)).
Anyway are problems in understanding really coming from number of features or more from the usage itself? How long is RegExp there? I am weak in RegExp (my fault), but sometimes i am using it and it is handy, BUT i've seen few professional devs 10+ years in a job staring long minutes into some weird RegExp not knowing how exactly(!) it works...
I agree this is nothing big like ES6. And I also kind of agree than less is more, but not always.
Most of it (all?) is already ready to use in chrome or Babel, optional chaining will be usable, waiting for it coming into chrome, Object.fromEntries() is usable, same with BigInt and Promise.allSettled - i am not even using any framework so cannot comment module import and i am not professional dev anyway, I just do not think things are black or white.
I'd say to 'know' javascript implies, at the very least, being handed any snippet of JS code (that's not written specifically to be unreadable) and being able to figure out what it does on a language-level without having to consult the documentation.
This is specially relevant in cases like the
?.
operator, which is hard to google when encountered in the wild.Agree. Let's just stick to C++, or better even, assembly language. Much less to learn!
I do agree this list didn't bring much to the table, though... (except the dynamic runtime imports perhaps?) They're might be more interesting things coming up. Were private fields mentioned here?
Nope I didn't mention that. Think that is still in stage 2..might be mistaken
TypeScript 3.7 already has an Optional Chaining:
Switch to TS, guys, and you won't have to wait 2020, lol.
😆😆😆 looool
Optional chaining! 🎉
Hell yeah!!!
The biggest question is browsers support for those amazing features
If you use a transpiler (eg, Babel/Typescript), they'll all be available
Optional Chaining is definitely my pick of the bunch here. The amount of time and hassle this will save is fantastic!
Thanks for sharing the good news!
Funny how those are all things that Ruby has had for ages now (except the promise-related one, which is obviously a javascript-specific feature).
Ohh man I love ruby. Reminds me of good ol days.
Nice piece with succinct examples, great work!
Thanks for this post! Very useful information!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.