Discussion :

[Bill Fassinou]

La spécification des nouvelles fonctionnalités de la norme ECMAScript 2021 a été officiellement approuvée
elle introduit des améliorations aux chaînes, à Promise et aux références d'objets

Modification du 24 juin 2021

ECMAScript 2021, la dernière version de la spécification officielle sous-jacente à JavaScript, a été officiellement approuvée ce 22 juin. Comme annoncé précédemment, les nouvelles fonctionnalités citées ci-dessous ont été retenues par l'ECMA International. Cette spécification introduit des améliorations aux chaînes, à Promise et aux références d'objets. ECMAScript 2021 suit ECMAScript 2020, qui a été officiellement approuvé en juin 2020.

Après ES20 ou ECMAScript 2020, correspondant à la version annuelle d'ECMAScript de 2020 ou à la 11e version du standard ECMAScript, l'ECMA International, l'organisation qui s'occupe de la normalisation du langage de script ECMAScript qui forme la base de JavaScript, a annoncé l'arrivée d'ECMAScript 2021. Lundi, elle a présenté une liste complète des nouveautés qui devraient être ajoutées au langage pour établir la norme ECMAScript 2021. Voici ci-dessous un aperçu des propositions de nouvelles fonctionnalités qui ont été retenues par l'ECMA International.

Bref rappel sur le standard ECMAScript de l'ECMA International

ECMAScript est un langage de script qui forme la base de plusieurs langages de script. Les langages tels que JavaScript, ActionScript et JavaScript sont tous basés sur la spécification ECMAScript. De même, JScript et TypeScript de Microsoft l'utilisent comme noyau. ECMAScript est standardisé par l'organisation ECMA International grâce aux spécifications ECMA-262 et ECMA-402. Le développement de la spécification du langage ECMAScript a commencé en novembre 1996. La première édition de cette norme Ecma a été adoptée par l'assemblée générale de l'ECMA en juin 1997.

Depuis la publication de la première édition de la spécification en 1997, ECMAScript est devenu l'un des langages de programmation à usage général les plus utilisés au monde. Il est surtout connu comme le langage intégré aux navigateurs Web, mais il a aussi été largement adopté pour les serveurs et les applications intégrées. Un nouveau standard ECMAScript, l'ECMAScript 2021 ou ES21, vient d'être approuvé et sera livré un peu plus tard dans l'année.

String.prototype.replaceAll()

Pour remplacer toutes les occurrences de chaînes, vous devez utiliser une combinaison de String.prototype.replace et de regexp globale. String.prototype.replaceAll() est une nouvelle méthode introduite par l'ECMA International dans la spécification qui simplifie cette opération. Selon les critiques, la popularité de la question "How to replace all occurrences of a string in JavaScript ?" sur StackOverflow prouve la nécessité de cette fonctionnalité dans le langage.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
const string = "it-is-just-a-test";
 
// instead of doing this
string.replace(/-/g, "_")
// "it_is_just_a_test"
 
// in ES2021 we can do
string.replaceAll("-", "_")
// "it_is_just_a_test"

Promise.any()

Les Promise ne sont pas un concept nouveau dans la communauté JavaScript. Elles existent dans l'écosystème depuis longtemps. Les Promise JavaScript existaient avant même qu'elles ne fassent officiellement partie de la spécification ECMAScript dans ES6. Ce sont des objets qui représentent l'achèvement ou l'échec éventuel d'une opération asynchrone, et la valeur qui en résulte. Il existe trois états possibles pour les Promise : en attente (état initial - toujours en attente), remplie (promesse réussie) et rejetée (Promise non tenue).

Si la Promise est soit remplie, soit rejetée, mais pas en attente, on dit qu'elle est réglée. Les combinateurs de Promise quant à eux sont utilisés pour faciliter le traitement des Promise. Le standard ECMAScript dispose actuellement de trois combinateurs de Promise, notamment Promise.all(), Promise.race(), Promise.allSettled(). ES21 en apporte une nouvelle. Promise.any() rejoint la liste des combinateurs de Promise dans le cahier des charges de cette année. Promise.any() est le dernier combinateur de promesses qui est maintenant à l'étape 3 du processus TC39.

Il prend un objet itérable et dès que l'une des Promise est remplie, il renvoie cette Promise. La différence entre cette méthode et Promise.all() est que Promise.all() renvoie un tableau de valeurs de réalisation alors que Promise.any() ne renvoie que la première valeur de réalisation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
const API = "https://api.github.com/users"
 
Promise.any([
  fetch(`${API}/pawelgrzybek`),
  fetch(`${API}/gabriel403`)
])
  .then(response => response.json())
  .then(({name}) => console.log(`Cool dude is: ${name}`))
  .catch(error => console.error(error));

La différence entre Promise.race() et Promise.any() est que Promise.race() renvoie la première valeur réglée (soit remplie, soit rejetée) alors que Promise.any() ignore les promesses rejetées jusqu'à la première promesse remplie. Si un itérable vide est passé, la méthode renvoie une Promise déjà résolue. Si toutes les Promise données sont rejetées, la méthode rejette de manière asynchrone avec une Erreur agrégée, une nouvelle sous-classe d'erreur qui regroupe les erreurs individuelles. Promise.any() est encore en phase expérimentale et n'est pas encore totalement prise en charge par les navigateurs.

WeakRefs et Finalizers

La proposition WeakRefs des contributeurs Dean Tribble et Sathya Gunasekaran a apporté deux nouveaux constructeurs, WeakRef et FinalizationRegistry. Ces nouvelles fonctionnalités sont des concepts linguistiques de niveau inférieur beaucoup plus compliqués.

• WeakRefs

WeakRef est l'abréviation de Weak References (références faibles). L'utilisation principale des références faibles est d'implémenter des caches ou des mappages vers de grands objets. Dans de tels scénarios, nous ne voulons pas garder beaucoup de mémoire pendant longtemps, en conservant ce cache ou ces mappages rarement utilisés. Vous pouvez permettre à la mémoire d'être collectée tôt ou tard et si vous en avez besoin à nouveau, vous pouvez générer un nouveau cache. Autrement dit, lorsque vous assignez un objet à une variable, il pointe vers le morceau de mémoire où la valeur de cet objet est stockée (référence forte).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
const obj = { spec: "ES2021" };
const objWeakRef = new WeakRef(obj);
 
// do something cool
 
objWeakRef.deref();
// returns obj in case it is still in memory
// returns undefined in case it has been garbage collected

Si le programme ne fait plus référence à cet objet, l'éboueur le détruit et récupère la mémoire. Une instance de WeakRef crée une référence à un objet donné qui le renvoie s'il est encore en mémoire ou indéfini dans le cas où l'objet cible aurait été récupéré.

• FinalizationRegistry

FinalizationRegistry est une fonction complémentaire de WeakRef. Il permet aux programmeurs d'enregistrer des rappels à invoquer après qu'un objet a été ramassé. Une instance de FinalizationRegistry déclenche une fonction de rappel après qu'un objet cible enregistré a été collecté. Mais attention, il faut éviter de les utiliser selon la recommandation de l'auteur de la proposition. Ces deux fonctionnalités reposent sur l'implémentation d'un collecteur d'ordures qui varie en fonction du moteur et de sa version.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
const obj = { spec: "ES2021" };
const registry = new FinalizationRegistry(value => {
    console.log(`The ${value} object has been garbage collected.`)
});
registry.register(obj, "ECMAScript 2021");
 
// perform some action that triggers garbage collector on obj
// The ECMAScript 2021 object has been garbage collected.

Logical Assignment Operators (opérateurs d'affection logique)

Comme son nom l'indique, la proposition d'affectation logique est la combinaison des opérateurs logiques (&&, || et ? ?) et de l'opérateur d'affectation (=). Un complément pratique au langage ! Jetez un coup d'œil.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var x = 1;
var y = 2;
x &&= y;
console.log(x); // 2

Le fonctionnement de la ligne 3 peut être étendu à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x && (x = y)

Ou dans un autre sens, c'est comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if(x) {
  x = y
}

Comme x est une valeur de vérité, on lui attribue la valeur de y, c'est-à-dire 2. Tout comme c'est fait avec &&, vous pouvez le faire avec les opérateurs || et ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
x &&= y;
x ||= y;
x ??= y;

Séparateurs numériques

Les grands nombres sont difficiles à lire. Grâce à Rick Waldron de l'équipe de contributeurs, vous pouvez maintenant séparer un groupe de chiffres en utilisant des traits de soulignement (_, U+005F). Cette fonctionnalité est bien connue d'autres langages de programmation comme Java, Python, Perl, Ruby, Rust, Julia, Ada, C#.

La version ECMAScript 2021 devrait être publiée au mois de juin 2021. Toutes les fonctionnalités énumérées ci-dessus sont déjà prises en charge dans la version Google Chrome Canary.

Source : ECMAScript 2021

Et vous ?

Que pensez-vous des nouvelles fonctionnalités introduites par ES21 ?
Quelles fonctionnalités vous attirent le plus dans cette nouvelle version d'ECMAScript ?
Quelles fonctionnalités aimeriez-vous voir apparaître dans la prochaine version du standard ECMAScript ?

Voir aussi

La version candidate d'ECMAScript 2020 est disponible avec l'ensemble des fonctionnalités finales, dont l'opérateur de coalescence nulle (??) et de chaînage optionnel (?.)

ECMAScript 2017 : Ecma International annonce les nouvelles mises à jour de ses spécifications pour les langages de script

ECMAScript 2016 : des mises à jour plus petites et plus fréquentes pour l'ensemble de normes des langages de script

Tutoriel présentant les nouveautés ECMAScript 6

[yahiko]

Le langage JavaScript continue d'évoluer et plutôt dans le bon sens.
Parmi les fonctionnalités vraiment intéressantes je note Promise.any() qui va faciliter la combinaison des promises.
Quant à WeakRef et FinalizationRegistry, ça devrait aider à limiter significativement les problèmes de "fuite de mémoire" en permettant de faire référence à un objet dans le cas où justement on souhaite gérer sa disparition sans créer de référence "forte".
Le reste des évolutions étant assez accessoire je trouve, mais pragmatique.

[melka one]

on peut aussi dire que Le langage JavaScript continue de se complexifier.

le choix est simple soit on simplifie un langage et on fait appel au raisonnement pour tous résoudre, soit on complexifie le langage en ajoutant de multiples méthode afin de gérer toutes situation aussi infime soient elles mais dans ce cas on fait plus appel a la mémoire afin justement de mémoriser toutes les méthode et leurs syntaxe et a un moment ca devient trop avec comme résultat l'augmentation de la courbe d'apprentissage

tous ça pour dire qu'il y a un juste milieux qui celons moi a été dépassé

quand a l'histoire des promesse en abuser devient imbuvable

[Doksuri]

j'ai du mal a comprendre dans quelle situation concrete, on aurait besoin du weakref...

Une instance de WeakRef crée une référence à un objet donné qui le renvoie s'il est encore en mémoire ou indéfini dans le cas où l'objet cible aurait été récupéré.

si on a besoin de tester la "suppression" de notre variable, c'est qu'on en a besoin non ?

1) creation de la variable weak
2) variable supprimee
3) on constate que notre variable est supprime
4) on la regenre car on en a besoin

? j'ai rate un concept ?

[Gugelhupf]

@Doksuri ,

Aujourd'hui de plus en plus d'opérations sont réalisés en JS, comme récupérer les données sur le navigateurs et réaliser ces opérations coté navigateur. Imagine que tu as une page avec un tableau contenant plusieurs milliers de lignes, puis tu as un carroussel qui te permet de passer d'un tableau à un autre, plus tu vas charger un nouveau tableau plus tu vas consommer de la mémoire, mais plus tu vas manquer de mémoire et plus les refs weaks seront supprimées. Donc oui, c'est de l'optimisation, si la ref weak est supprimée tu recharges... mais seulement si elle est supprimée

A+

[Doksuri]

Imagine que tu as une page avec un tableau contenant plusieurs milliers de lignes, puis tu as un carroussel qui te permet de passer d'un tableau à un autre, plus tu vas charger un nouveau tableau plus tu vas consommer de la mémoire

soit tu creees, tous tes tableaux dans le DOM, et ta grosse variable sera supprimee d'elle-meme (et le carroussel fait juste un display:block/none sur le tableau conserne)
soit tu fais un appel ajax pour charger une nouveau tableau (et dans ce cas, chaque tableau est "ephemere")

(il y a vraiment quelque chose que je rate la

[frfancha]

Tu mets tes données en weak cache. Du coup ça laisse le JavaScript engine décider si il les enlève ou pas en fonction des besoins.
Quand toi tu as de nouveau besoin des données tu les lis de la weak cache. Si elles y sont encore tant mieux, sinon tu les reconstruis par exemple en devant les relire du serveur

[melka one]

jour

on peut aussi dire tu te prend la tête en mettant des conditions et en priant pour que quand tu a besoin des donné elles y sont encore et si c'est pas le cas la a wall agains weak cache te sert a rien a part complexifier la chose.

[grunk]

j'ai du mal a comprendre dans quelle situation concrete, on aurait besoin du weakref...

Ca permet simplement d'éviter de maintenir une référence forte vers un objet et d'empêcher le garbage collector de passer dessus alors même qu'il n'est pas forcément utilisé.
L'exemple assez typique c'est sur de la gestion d'événement.

Par exemple tu as un as gestionnaire d'événement qui doit invoquer un objet. Potentiellement cet événement peut ne jamais être appelé (si l'utilisateur ne clic jamais au bon endroit par exemple) mais va garder une référence vers l'objet en question et empécher sa suppression.
Alors que si on utilise une weakreference , on n'empèche pas la suppression de l'objet et on aura juste à vérifier dans notre gestionnaire d'événement que l'objet est disponible avant de l'utiliser.

Sur des script js web classique ca n'a aucun intérêt. En revanche sur du SPA ou du code node qui vit longtemps ca peut permettre d'éviter des fuites mémoires.

[TotoParis]

Encore plus de sites dysfonctionnels à l'horizon.

[Dave Hiock]

\ô/

... plus de sites dysfonctionnels à l'horizon.

Décidément tu fais une fixette avec les évolutions

une de tes participations !

[Lcf.vs]

j'ai du mal a comprendre dans quelle situation concrete, on aurait besoin du weakref...

si on a besoin de tester la "suppression" de notre variable, c'est qu'on en a besoin non ?

1) creation de la variable weak
2) variable supprimee
3) on constate que notre variable est supprime
4) on la regenre car on en a besoin

? j'ai rate un concept ?

Un exemple concret où il peut sacrément être utile, dans une page web, c'est le cas du MutationObserver...

D'après la spec, si l'observer n'observe plus rien, il est garbage-collected, ce qui implique qu'il est prévu pour ne pas être actif plus que nécessaire, cependant, lorsqu'on veut le réutiliser, on a besoin de le stocker dans une variable, empêchant son nettoyage.

À la place, si tu le stockes dans une WeakRef, il peut être nettoyé, tout en préservant sa référence d'ici-là.

Si tu en as de nouveau besoin, tu peux récupérer la valeur de la référence, si elle n'a pas été nettoyée, tu réutilises l'observer courant, sinon, tu sais que tu dois le réinstancier et le re-stocker.