JavaScript mis à jour en es

JavaScript a été mis à jour vers es13. Le 22 juin 2022, la 123e conférence Ecma a approuvé la spécification du langage ECMAScript2022, ce qui signifie qu'elle est désormais officiellement devenue une norme JavaScript et ECMAScript2022 en est la 13e itération, elle peut donc également être appelée ECMAScript13, ou ES13 en abrégé.

L'environnement d'exploitation de ce tutoriel : système Windows 7, ECMAScript version 13, ordinateur Dell G3.

La nouvelle spécification ES13 est enfin publiée.

JavaScript n'est pas un langage open source, c'est un langage qui doit être écrit conformément à la spécification standard ECMAScript. Le comité TC39 est chargé de discuter et d'approuver la sortie des nouvelles fonctionnalités. Alors, qui sont ces TC39 ?

« Le TC39 d'ECMA International est un groupe de développeurs, implémenteurs, universitaires, etc. JavaScript qui travaillent avec la communauté pour maintenir et faire évoluer la définition de JavaScript. » — TC39.es

Leur processus de publication comprend cinq étapes, commençant par 2015 Depuis, ils font des sorties annuelles, et elles ont généralement lieu au printemps.

Le 22 juin 2022, le 123ème Congrès Ecma a approuvé la spécification du langage ECMAScript 2022, ce qui signifie qu'il s'agit désormais officiellement d'un standard.

Il existe deux manières de référencer n'importe quelle version d'ECMAScript :

• Par année : Cette nouvelle version sera ES2022.

• Par son numéro d'itération : Cette nouvelle version sera la 13ème itération, elle pourra donc s'appeler ES13.

Alors quoi de neuf dans cette version cette fois-ci ? De quelles fonctionnalités pouvons-nous être enthousiasmés ?

01, Index de correspondance d'expression régulière

Actuellement, lors de l'utilisation de l'API JavaScript Regex en JavaScript, seul l'index de départ de la correspondance est renvoyé. Toutefois, pour certains scénarios avancés particuliers, cela ne suffit pas.

Dans le cadre de ce cahier des charges, un drapeau spécial d a été ajouté. En utilisant cela, l'API d'expression régulière renverra un tableau à deux dimensions comme clé de l'index du nom. Il contient l'index de début et de fin de chaque match. Si des groupes nommés sont capturés dans l'expression régulière, ils renverront leurs indices de début/fin dans l'objet indices.groups, le nom du groupe nommé étant sa clé.

// ✅ a regex with a 'B' named group capture
const expr = /a+(?<B>b+)+c/d;


const result = expr.exec("aaabbbc")


// ✅ shows start-end matches + named group match
console.log(result.indices);
// prints [Array(2), Array(2), groups: {…}]


// ✅ showing the named &#39;B&#39; group match
console.log(result.indices.groups[&#39;B&#39;])
// prints [3, 6]

Voir la proposition originale, https://github.com/tc39/proposal-regexp-match-indices

02, attente de niveau supérieur

Avant cette proposition, l'attente de niveau supérieur n'est pas accepté, il existe des solutions de contournement pour simuler ce comportement, mais elles présentent des inconvénients.

La fonctionnalité d'attente de haut niveau nous permet de nous appuyer sur des modules pour gérer ces promesses. Il s'agit d'une fonctionnalité intuitive.

Mais veuillez noter que cela peut changer l'ordre d'exécution des modules. Si un module dépend d'un autre module avec un appel d'attente de niveau supérieur, l'exécution du module sera suspendue jusqu'à ce que la promesse soit terminée.

Regardons un exemple :

// users.js
export const users = await fetch('/users/lists');


// usage.js
import { users } from "./users.js";
// ✅ the module will wait for users to be fullfilled prior to executing any code
console.log(users);

Dans l'exemple ci-dessus, le moteur attendra que l'utilisateur termine l'action avant d'exécuter le code sur le module usage.js.

Dans l’ensemble, c’est une fonctionnalité agréable et intuitive qui doit être utilisée avec précaution et n’en abusons pas.

Voir la proposition originale ici. https://github.com/tc39/proposal-top-level-await

03, .at( )

Depuis longtemps, il y a des demandes pour que JavaScript fournisse un accesseur d'index négatif de type Python pour les tableaux. Au lieu de faire array[array.length-1], faites simplement array[-1]. Cela n'est pas possible car le symbole [] est également utilisé pour les objets en JavaScript.

La proposition acceptée adoptait une approche plus pratique. Les objets tableau auront désormais une méthode pour simuler le comportement ci-dessus.

const array = [1,2,3,4,5,6]


// ✅ When used with positive index it is equal to [index]
array.at(0) // 1
array[0] // 1


// ✅ When used with negative index it mimicks the Python behaviour
array.at(-1) // 6
array.at(-2) // 5
array.at(-4) // 3

Voir la proposition originale, https://github.com/tc39/proposal-relative-indexing-method

Au fait, puisque nous parlons de tableaux, saviez-vous que vous pouvez déstructurer les positions des tableaux ?

const array = [1,2,3,4,5,6];


// ✅ Different ways of accessing the third position
const {3: third} = array; // third = 4
array.at(3) // 4
array[3] // 4

04, accessible Object.prototype.hasOwnProperty

Ce qui suit n'est qu'une bonne simplification, a déjà hasOwnProperty. Cependant, il doit être appelé dans l'instance de recherche que nous souhaitons effectuer. Il est donc courant que de nombreux développeurs finissent par faire cela :

const x = { foo: "bar" };


// ✅ grabbing the hasOwnProperty function from prototype
const hasOwnProperty = Object.prototype.hasOwnProperty


// ✅ executing it with the x context
if (hasOwnProperty.call(x, "foo")) {
  ...
}

Avec ces nouvelles spécifications, une méthode hasOwn a été ajoutée au prototype Object, et maintenant, nous pouvons simplement faire :

const x = { foo: "bar" };


// ✅ using the new Object method
if (Object.hasOwn(x, "foo")) {
  ...
}

Voir la proposition originale, https:/// github.com/tc39/proposal-accessible-object-hasownproperty

05、Cause de l'erreur

错误帮助我们识别应用程序的意外行为并做出反应，然而，理解深层嵌套错误的根本原因，正确处理它们可能会变得具有挑战性，在捕获和重新抛出它们时，我们会丢失堆栈跟踪信息。

没有关于如何处理的明确协议，考虑到任何错误处理，我们至少有 3 个选择：

async function fetchUserPreferences() {
  try { 
    const users = await fetch('//user/preferences')
      .catch(err => {
        // What is the best way to wrap the error?
        // 1. throw new Error('Failed to fetch preferences ' + err.message);
        // 2. const wrapErr = new Error('Failed to fetch preferences');
        //    wrapErr.cause = err;
        //    throw wrapErr;
        // 3. class CustomError extends Error {
        //      constructor(msg, cause) {
        //        super(msg);
        //        this.cause = cause;
        //      }
        //    }
        //    throw new CustomError('Failed to fetch preferences', err);
      })
    }
}


fetchUserPreferences();

作为这些新规范的一部分，我们可以构造一个新错误并保留获取的错误的引用。 我们只需将对象 {cause: err} 传递给 Errorconstructor。

这一切都变得更简单、标准且易于理解深度嵌套的错误， 让我们看一个例子：

async function fetcUserPreferences() {
  try { 
    const users = await fetch('//user/preferences')
      .catch(err => {
        throw new Error('Failed to fetch user preferences, {cause: err});
      })
    }
}


fetcUserPreferences();

了解有关该提案的更多信息，https://github.com/tc39/proposal-error-cause

06、Class Fields

在此版本之前，没有适当的方法来创建私有字段， 通过使用提升有一些方法可以解决它，但它不是一个适当的私有字段。 但现在很简单， 我们只需要将 # 字符添加到我们的变量声明中。

class Foo {
  #iteration = 0;


  increment() {
    this.#iteration++;
  }


  logIteration() {
    console.log(this.#iteration);
  }
}


const x = new Foo();


// ❌ Uncaught SyntaxError: Private field '#iteration' must be declared in an enclosing class
x.#iteration


// ✅ works
x.increment();


// ✅ works
x.logIteration();

拥有私有字段意味着我们拥有强大的封装边界， 无法从外部访问类变量，这表明 class 关键字不再只是糖语法。

我们还可以创建私有方法：

class Foo {
  #iteration = 0;


  #auditIncrement() {
    console.log('auditing');
  }


  increment() {
    this.#iteration++;
    this.#auditIncrement();
  }
}


const x = new Foo();


// ❌ Uncaught SyntaxError: Private field '#auditIncrement' must be declared in an enclosing class
x.#auditIncrement


// ✅ works
x.increment();

该功能与私有类的类静态块和人体工程学检查有关，我们将在接下来的内容中看到。

了解有关该提案的更多信息，https://github.com/tc39/proposal-class-fields

07、Class Static Block

作为新规范的一部分，我们现在可以在任何类中包含静态块，它们将只运行一次，并且是装饰或执行类静态端的某些字段初始化的好方法。

我们不限于使用一个块，我们可以拥有尽可能多的块。

// ✅ will output 'one two three'
class A {
  static {
      console.log('one');
  }
  static {
      console.log('two');
  }
  static {
      console.log('three');
  }
}

他们有一个不错的奖金，他们获得对私有字段的特权访问， 你可以用它们来做一些有趣的模式。

let getPrivateField;


class A {
  #privateField;
  constructor(x) {
    this.#privateField = x;
  }
  static {
    // ✅ it can access any private field
    getPrivateField = (a) => a.#privateField;
  }
}


const a = new A('foo');
// ✅ Works, foo is printed
console.log(getPrivateField(a));

如果我们尝试从实例对象的外部范围访问该私有变量，我们将得到无法从类未声明它的对象中读取私有成员#privateField。

了解有关该提案的更多信息，https://github.com/tc39/proposal-class-static-block

08、Private Fields

新的私有字段是一个很棒的功能，但是，在某些静态方法中检查字段是否为私有可能会变得很方便。

尝试在类范围之外调用它会导致我们之前看到的相同错误。

class Foo {
  #brand;


  static isFoo(obj) {
    return #brand in obj;
  }
}


const x = new Foo();


// ✅ works, it returns true
Foo.isFoo(x);


// ✅ works, it returns false
Foo.isFoo({})


// ❌ Uncaught SyntaxError: Private field '#brand' must be declared in an enclosing class
#brand in x

了解有关该提案的更多信息。https://github.com/tc39/proposal-private-fields-in-in

最后的想法

这是一个有趣的版本，它提供了许多小而有用的功能，例如 at、private fields和error cause。当然，error cause会给我们的日常错误跟踪任务带来很多清晰度。

一些高级功能，如top-level await，在使用它们之前需要很好地理解。它们可能在你的代码执行中产生不必要的副作用。

【相关推荐：javascript视频教程、编程视频】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!