39 articles tagués avec « ECMAScript »

La proposition Gestion Explicite des Ressources introduit une approche déterministe pour gérer explicitement le cycle de vie des ressources telles que les gestionnaires de fichiers, les connexions réseau, et plus encore. Cette proposition apporte les ajouts suivants au langage : les déclarations using et await using, qui appellent automatiquement la méthode de disposition lorsqu'une ressource sort de leur champ d'application ; les symboles [Symbol.dispose]() et [Symbol.asyncDispose]() pour les opérations de nettoyage ; deux nouveaux objets globaux DisposableStack et AsyncDisposableStack en tant que conteneurs pour agréger les ressources jetables ; et SuppressedError comme nouveau type d'erreur (contient à la fois l'erreur la plus récemment levée, ainsi que l'erreur supprimée) pour gérer le scénario où une erreur se produit lors de la disposition d'une ressource, masquant potentiellement une erreur existante levée dans le corps, ou lors de la disposition d'une autre ressource. Ces ajouts permettent aux développeurs d'écrire un code plus robuste, performant et maintenable en offrant un contrôle précis sur la disposition des ressources.

Les assistants d'itérateurs sont une collection de nouvelles méthodes sur le prototype d'Iterator qui aident à l'utilisation générale des itérateurs. Puisque ces méthodes d'assistance se trouvent sur le prototype d'Iterator, tout objet qui possède Iterator.prototype dans sa chaîne de prototypes (par exemple, les itérateurs de tableau) héritera des méthodes. Dans les sous-sections suivantes, nous expliquons les assistants d'itérateurs. Tous les exemples fournis fonctionnent sur une page d'archive de blog contenant une liste d'articles de blog, illustrant comment les assistants d'itérateurs sont utiles pour rechercher et manipuler des articles. Vous pouvez les essayer sur la page du blog V8 !

Précédemment​

V8 a introduit la fonctionnalité import assertions dans la version 9.1. Cette fonctionnalité permettait aux déclarations d'importation de modules d'inclure des informations supplémentaires en utilisant le mot-clé assert. Ces informations supplémentaires sont actuellement utilisées pour importer des modules JSON et CSS à l'intérieur des modules JavaScript.

JavaScript prend en charge les expressions régulières depuis ECMAScript 3 (1999). Seize ans plus tard, ES2015 a introduit le mode Unicode (l'indicateur u), le mode sticky (l'indicateur y), et l'accessoire flags de RegExp.prototype. Trois ans plus tard, ES2018 a introduit le mode dotAll (l'indicateur s), les assertions en arrière-plan, les groupes capturants nommés, et les échappements des propriétés des caractères Unicode. Et dans ES2020, String.prototype.matchAll a facilité l'utilisation des expressions régulières. Les expressions régulières JavaScript ont parcouru un long chemin et continuent de s'améliorer.

Trouver des éléments depuis le début​

Trouver un élément qui satisfait une condition dans un Array est une tâche courante et se fait avec les méthodes find et findIndex sur Array.prototype et les divers prototypes TypedArray. Array.prototype.find prend un prédicat et retourne le premier élément dans le tableau pour lequel ce prédicat retourne true. Si le prédicat ne retourne true pour aucun élément, la méthode retourne undefined.

La nouvelle méthode at sur Array.prototype, les différents prototypes de TypedArray et String.prototype facilite et rend plus succincte l'accès à un élément proche de la fin de la collection.

Accéder au Nième élément depuis la fin d'une collection est une opération courante. Cependant, les façons habituelles de le faire sont verbeuses, comme my_array[my_array.length - N], ou pourraient ne pas être performantes, comme my_array.slice(-N)[0]. La nouvelle méthode at rend cette opération plus ergonomique en interprétant les indices négatifs comme signifiant « depuis la fin ». Les exemples précédents peuvent être exprimés comme my_array.at(-N).

Imaginez que vous avez une fonction qui appelle deux charges de travail distinctes doSomeWork et doMoreWork. Les deux fonctions peuvent lancer le même type d'erreurs, mais vous devez les traiter de manière différente.

Attraper l'erreur et la relancer avec des informations contextuelles supplémentaires est une approche courante à ce problème, par exemple :

function doWork() {
  try {
    doSomeWork();
  } catch (err) {
    throw new CustomError('Échec d'une tâche', err);
  }
  doMoreWork();
}

try {
  doWork();
} catch (err) {
  // Est-ce que |err| vient de |doSomeWork| ou de |doMoreWork| ?
}

Malheureusement, la solution ci-dessus est laborieuse, car il faut créer son propre CustomError. Et pire encore, aucun outil de développement n'est capable de fournir des messages de diagnostic utiles pour les exceptions inattendues, car il n'y a pas de consensus sur la manière de représenter correctement ces erreurs.

Aujourd'hui, il est très courant d'écrire du code comme celui-ci :

const hasOwnProperty = Object.prototype.hasOwnProperty;

if (hasOwnProperty.call(object, 'foo')) {
  // `object` possède la propriété `foo`.
}

Ou d'utiliser des bibliothèques qui exposent une version simplifiée de Object.prototype.hasOwnProperty, telles que has ou lodash.has.

Avec la proposition Object.hasOwn, nous pouvons simplement écrire :

if (Object.hasOwn(object, 'foo')) {
  // `object` possède la propriété `foo`.
}

Object.hasOwn est déjà disponible dans V8 v9.3 derrière le drapeau --harmony-object-has-own, et nous le déploierons bientôt dans Chrome.

Support de Object.hasOwn​

La nouvelle fonctionnalité assertions d'importation permet aux instructions d'importation de module d'inclure des informations supplémentaires en plus du spécificateur de module. Une utilisation initiale de cette fonctionnalité est de permettre l'importation de documents JSON sous forme de modules JSON :

L'opérateur in peut être utilisé pour tester si l'objet donné (ou tout objet dans sa chaîne de prototypes) possède la propriété donnée :

const o1 = {'foo': 0};
console.log('foo' in o1); // true
const o2 = {};
console.log('foo' in o2); // false
const o3 = Object.create(o1);
console.log('foo' in o3); // true

La fonctionnalité des vérifications des marques privées étend l'opérateur in pour prendre en charge les champs privés des classes:

class A {
  static test(obj) {
    console.log(#foo in obj);
  }
  #foo = 0;
}

A.test(new A()); // true
A.test({}); // false

class B {
  #foo = 0;
}

A.test(new B()); // false; ce n'est pas le même #foo

Puisque les noms privés ne sont disponibles qu'à l'intérieur de la classe qui les définit, le test doit également avoir lieu à l'intérieur de la classe, par exemple dans une méthode comme static test ci-dessus.

Les instances de sous-classe reçoivent les champs privés de la classe parente en tant que propriétés propres :

class SubA extends A {};
A.test(new SubA()); // true

Mais les objets créés avec Object.create (ou dont le prototype est défini ultérieurement via le modificateur __proto__ ou Object.setPrototypeOf) ne reçoivent pas les champs privés en tant que propriétés propres. Comme la recherche de champs privés ne fonctionne que sur les propriétés propres, l'opérateur in ne trouve pas ces champs hérités :