4 New Exciting Features Coming in ECMAScript 2021
Let’s face it, 2020 has probably earned its place in the top 5 worst years in the history list. And don’t get me wrong, we got some interesting releases during 2020 such as Deno and TypeScript 4.0, but let’s try to forget about 2020 and start thinking about 2021, which with any luck, it’ll be a lot better (including a COVID-19 vaccine).
And particularly, in 2021, we get a new version of ECMAScript (or as we commonly know it, JavaScript), which means there is some goodness waiting for us around the corner. And in this article, I’m going to give you a quick overview as to what that might be.
replaceAll string method
This one is a long time coming method, I mean, the currently existing replace method should’ve implemented something like this long time ago. In case you’re not aware, currently the replace method from the String object only affects the first match found, unless of course, if you use a regular expression instead of a simple string as the first parameter.
Granted, this is not really a big improvement, more of a convenient addition, but still, it’s definitely appreciated.
Tip: Share your reusable components between projects using Bit (Github). Bit makes it simple to share, document, and organize independent components from any project.
Use it to maximize code reuse, collaborate on independent components, and build apps that scale.
Bit supports Node, TypeScript, React, Vue, Angular, and more.
Private visibility modifier for methods and accessors
Still, no news on private properties being a thing (right now the proposal is still sitting on stage 3), but as a taste of what’s to come, we’ll be able to set visibility on both, class methods and accessors. And by “visibility” I mean we can set them as private, which means we’ll finally have a basic way of protecting our code and slowly start moving towards a more OOP-oriented way of coding (not that there is anything wrong with the functional approach we have right now).
Essentially, you’re using the # character to specify when either the method or the accessor is private. That character also becomes part of the name, so if you wanted to use either of the two I mentioned above, you can simply do this.#Age or this.#myPrivateMethod(). In both cases, an exception will be thrown if you try to use them from outside the class or even from inside a class that extends this one (we’ll have to wait until we have protected methods for that).
Finalizers and WeakRefs
These are two interesting tools we get to help us deal with memory usage and to control how our objects get garbage collected. Probably not something you’ll ever use unless you have the need to be particularily careful about memory utilization, but nevertheless, it’s right there for you to use.
A note of warning: the following two functionalitites deal with how the garbage collector works, but that implementation is specific to each runtime. This means writing business logic that depends on non-standard implementations is probably going to yield unexpected results. You have the tools, but be very aware of what you’re doing before using them.
WeakRefs
Before we cover Weak References, let me quickly cover their opposite: Strong References, in order to understand what’s the benefit of the first one.
A Strong Reference is essentially a pointer to your objects and in JavaScript, that just means a variable in which you’ve assigned the object to. For example:
class Person {
constructor(first_name, last_name) {
this.first_name = first_name;
this.last_name = last_name;
}
}let myP = new Person("Fernando", "Doglio")
In the above context, myP will be a valid strong reference until it no longer lives. Once all strong references to an object are eliminated, then the Garbage Collector is free to destroy that object and release its memory so it can be used for other things.
That being said, there are cases, such as the following where strong references might lock down an objec to the point where it can never be released:
class Person {
constructor(first_name, last_name) {
this.first_name = first_name;
this.last_name = last_name;
this.sibling = null; }
}last me = new Person("Fernando", "Doglio");
last sibling = new Person("My", "Sibling");
me.sibling = sibling;
sibling.sibling = me;
In the above example, both objects are referencing each other, so even when both the me and sibling variables are left out of scope and thus, de-referenced, internally each object holds a strong reference for the other. In practice this means these objects will never be collected.
Is this a problem? Not at all, unless of course, you’re using JS in a device with very little memory.
Enter WeakRefs
Now that we understand Strong references, a WeakRef is essentially a way to keep a reference to an object without affecting the behavior of the garbage collector. In the previous example, if your sibling properties would’ve been set using the WeakRef construct, then these objects would’ve been able to be collected.
Another use case for weak references are cache structures, because you don’t want the cache’s internal references to objects to keep these objects alive more then they should.
The above example is a very basic example of what a cache should be, but go with it, would you? The point here is that using the WeakRef object is as simple as that. Just remember that if you’re trying to access the object being refereced, you need to use the deref method. And because this is a weak reference, you need to check for the return value of deref, if it’s undefined it means the object is no longer alive, otherwise you caan safely use it (hence the IF check in the get method.
Finalizers
Now the cherrie on top, finalizers allow you to react to the fact that your weakly referenced objects get garbage collected. Again, this is highly implementation-specific, but here is how you use it:
Essentially you create a registry using FinalizationRegistry which takes a callback function as parameter. This function will get called everytime an object (previously registered using the register method) is collected.
The register method itself is the one you use to specify which object’s restruction you’re waiting for and the second argument of it, is the value that will be passed to the callback you originally defined when creating the registry.
I would suggest you stay relatively away from this, especially don’t create business logic around this method, but consider using it in those particular cases when you need to debug strange behaviors.
Promise.any
Yet another method to handle multiple simultaneous promises is added in this version of ECMAScript. Essentially, the any method allows you to run multiple promises and resolve with the first settled promise or wait until all of them fail and returns an AggregateError object (which is a sub-class of the Error object).
So what’s the difference between any and race (because they sound very much alike)? Great question! The fact of the matter is that the latter would settle as soon as one of the promises would fulfill or fail and it would return that value. However, any will either be settled with the first settled value or wait for all of them to fail, and then return all errors together.
Notice how any is actually ignoring the first rejected promise because there are others being resolved. That is the main difference between race and any .
Conclusion
That’s it for ECMAScript 2021, not a lot of new features, but the ones that have been accepted look very good to me!
Remember, careful how you use the WeakRef and FinalizationRegistry objects, they provide very interesting functionalities but they might not deal the same results or behave in the same way between runtimes.
What was your favorite new feature? What are you most excited about for this release? Leave a commend down below, I’d love to know about it!
