J'ai récemment écrit sur les nouvelles fonctionnalités introduites dans ES2020... Si certaines de ces possibilités sont assez intéressantes, aucune ne mérite d'être qualifiée de «révolutionnaire». Cela est compréhensible étant donné que la spécification JS est mise à jour assez souvent ces jours-ci. Il s'avère que ceux qui travaillent sur la norme ont tout simplement moins de possibilités d'introduire constamment quelque chose de spécial dans le langage, comme des modules ES6 ou des fonctions fléchées. Mais cela ne signifie pas que quelque chose d'exclusivement nouveau n'apparaîtra pas dans la langue. En fait, c'est ce dont je veux parler aujourd'hui. Je voudrais parler de 4 possibilités qui, à long terme, peuvent être qualifiées de révolutionnaires. Ils sont maintenant à différentes étapes du processus.
coordination des propositions. Cela signifie d'une part que nous ne les verrons peut-être jamais en JavaScript et, d'autre part, la présence de telles phrases nous donne l'espoir que nous les rencontrerons néanmoins un jour dans la langue.
Décorateurs
Nous allons commencer par la fonctionnalité qui est probablement la plus fréquemment demandée pour être incluse dans la langue, et autour de laquelle il y a beaucoup de buzz. Il y a quelques années, ils ont écrit sur elle littéralement partout. Il s'agit de décorateurs .
Vous connaissez peut-être déjà les décorateurs. Surtout si vous écrivez en TypeScript. Il s'agit, en substance, d'un concept de métaprogrammation visant à donner au développeur la possibilité «d'injecter» ses propres fonctionnalités dans les classes, dans leurs champs et méthodes individuels, rendant finalement les classes programmables.
Jetez un œil à l'exemple suivant:
function sealed(constructor: Function) {
Object.seal(constructor);
Object.seal(constructor.prototype);
}
@sealed
class Greeter {
greeting: string;
constructor(message: string) {
this.greeting = message;
}
greet() {
return "Hello, " + this.greeting;
}
}
Ici, j'ai décidé de procéder avec prudence et j'ai donné un exemple d'utilisation de décorateurs TypeScript . Je l'ai fait principalement pour montrer l'idée générale. Dans l'extrait de code ci-dessus, nous avons créé un décorateur
sealedet l' avons appliqué à la classe Greeter. Comme vous pouvez facilement le voir, un décorateur est simplement une fonction qui a accès au constructeur de la classe à laquelle il est appliqué (c'est la cible). Nous utilisons une référence à un constructeur, ainsi qu'une méthode Object.seal()pour rendre la classe non extensible.
Pour appliquer un décorateur à une classe, nous écrivons le nom du décorateur avec une icône
@juste avant la déclaration de classe. Le résultat est que l'avant de la déclaration de classe apparaît une conception de type @[name], qui dans notre cas ressemble à @sealed.
Vous pouvez vérifier la fonctionnalité du décorateur en compilant ce code TS avec l'option activée
experimentalDecoratorset en essayant de changer le prototype de classe:
Greeter.prototype.test = "test"; // ERROR
En conséquence, vous devriez maintenant avoir une compréhension générale des raisons pour lesquelles les décorateurs sont nécessaires. Mais je voudrais aborder ici une question difficile. Il concerne l'état d'approbation de la proposition de décorateurs.
J'ai décidé d'utiliser TypeScript pour démontrer les décorateurs pour une bonne raison. Le fait est qu'une proposition d'intégration de décorateurs dans JavaScript existe il y a quelques années. Et c'est maintenant "seulement" au 2ème stade de l'accord sur 4. Tant la syntaxe que les capacités des décorateurs de cette proposition sont constamment modifiées. Mais cela n'empêche pas la communauté JS d'utiliser ce concept. Pour en être convaincu, il suffit de regarder d'énormes projets open source comme TypeScript ou Angular v2 +.
Certes, tout cela, au fil du temps, et au fur et à mesure de l'évolution de la proposition, conduit à un problème lié à l'incompatibilité des spécifications. À savoir, la spécification du décorateur a beaucoup évolué depuis l'apparition de la proposition, mais de nombreux projets ne l'ont toujours pas mise en œuvre. L'exemple TypeScript présenté ci-dessus est une démonstration de l'implémentation d'une ancienne version de la proposition. On peut en dire autant d'Angular, et même de Babel (bien que, dans le cas de Babel, on puisse dire que des travaux sont actuellement en cours pour implémenter une nouvelle version de cette spécification). En général, la version la plus récente de la proposition, qui utilise un mot
decorator- clé et une syntaxe adaptés à la liaison, n'a pas encore trouvé d'utilisation notable.
L'essentiel est que les décorateurs ont le potentiel de changer la façon dont nous écrivons le code. Et ces changements se manifestent déjà, même si les décorateurs en sont encore à leurs débuts. Cependant, étant donné l'état actuel des choses, les décorateurs ne font que fragmenter la communauté, et je pense qu'ils ne sont pas encore prêts pour un usage vraiment sérieux. Je conseillerais à ceux qui s'intéressent aux décorateurs d'attendre un peu avant de les introduire en production. Ma recommandation, cependant, ne s'applique pas à ceux qui utilisent des frameworks qui utilisent des décorateurs (comme Angular).
Royaumes
Maintenant, ralentissons un peu et parlons d'une fonctionnalité qui n'est pas aussi complexe que les décorateurs. Nous parlons de zones .
Vous avez peut-être déjà été dans des situations où vous devez exécuter votre propre code ou du code tiers, mais en même temps, faites-le de manière à ce que ce code n'affecte pas l'environnement global. De nombreuses bibliothèques, en particulier celles de navigateur, fonctionnent via l'objet global
window. En conséquence, ils peuvent interférer les uns avec les autres dans le cas où le projet utilise trop de bibliothèques non contrôlées par le développeur. Cela peut entraîner des erreurs.
La solution actuelle du navigateur à ce problème consiste à utiliser les éléments
<iframe>, et dans certains cas particuliers - dans l'utilisation de web workers. Dans l'environnement Node.js, le même problème est résolu à l'aide d'un module vmou à l'aide de processus enfants . L'API Realms est conçue pour résoudre ces problèmes.
Cette API vise à permettre aux développeurs de créer des environnements globaux séparés appelés étendues. Chacun de ces domaines a ses propres entités mondiales. Jetez un œil à l'exemple suivant:
var x = 39;
const realm = new Realm();
realm.globalThis.x; // undefined
realm.globalThis.x = 42; // 42
realm.globalThis.x; // 42
x; // 39
Ici, nous créons un nouvel objet en
Realmutilisant le constructeur approprié. Désormais, nous avons un accès complet à la nouvelle étendue et à ses objets globaux via une propriété globalThis(introduite dans ES2020). Ici, vous pouvez voir que les variables de l '«incubateur» principal sont séparées des variables de la portée que nous avons créée.
Dans l'ensemble, l'API Realms se veut un mécanisme très simple, mais un mécanisme utile. Cette API a un ensemble très spécifique de cas d'utilisation. Cela ne nous donne pas un niveau de sécurité plus élevé, ni la capacité de code multithread. Mais il s'acquitte parfaitement, sans créer de charge inutile sur le système, de sa tâche principale, en fournissant des capacités de base pour créer des environnements isolés.
La proposition d'API Realms est actuellement en phase 2 de négociation. Lorsqu'il atteindra finalement la norme, on s'attendrait à ce qu'il soit utilisé dans des bibliothèques "lourdes" qui reposent sur la portée globale, dans des éditeurs de code en sandbox en ligne, dans diverses applications ciblant essai.
Faire des expressions
La syntaxe JavaScript, comme la syntaxe de la plupart des langages de programmation, comprend des instructions et des expressions. La différence la plus notable entre ces constructions est que les expressions peuvent être utilisées comme valeurs (c'est-à-dire qu'elles peuvent être affectées à des variables, passées à des fonctions, etc.), tandis que les instructions ne peuvent pas être utilisées en tant que telles.
En raison de cette distinction, les expressions sont le choix le plus préféré pour un code plus propre et plus compact. En JavaScript, vous pouvez voir cela en regardant la popularité des expressions de fonction, qui incluent les fonctions fléchées, par rapport aux déclarations de fonction, aux instructions de fonction. La même situation est observée si nous comparons les méthodes d'itération sur des tableaux (comme
forEach()) avec des cycles. Il en va de même pour les programmeurs plus avancés en comparant l' opérateur ternaire et l'instruction if.
La proposition do-expression , actuellement en phase de négociation 1, vise à améliorer encore les capacités des expressions JS. Et, en passant, ne confondez pas le concept de "do-expression" avec des boucles
do…while, car ce sont des choses complètement différentes.
Voici un exemple:
let x = do {
if (foo()) {
f();
} else if (bar()) {
g();
} else {
h();
}
};
Voici la syntaxe de la clause do-expression. En général, nous avons devant nous un morceau de code JS enveloppé dans une construction
do {}. La dernière expression de cette construction est «renvoyée» comme valeur finale de l'expression do entière.
Un effet similaire (mais non identique) peut être obtenu en utilisant une IIFE (expression de fonction immédiatement invoquée). Mais dans le cas des do-expressions, leur syntaxe compacte semble très attractive. Ici, avec des fonctionnalités similaires, vous n'avez pas besoin ni de
returnstructures auxiliaires laides comme(() => {})()... C'est pourquoi je pense qu'une fois que les expressions entreront dans la norme, leur impact sur JavaScript sera comparable à celui des fonctions fléchées. La commodité des expressions et la syntaxe conviviale, pour ainsi dire, dans un seul paquet, semblent très tentantes.
Correspondance de motif
Cette opportunité est la dernière de ce matériel, mais elle est loin d'être la dernière en importance. Il s'agit d'une proposition visant à introduire un mécanisme de correspondance de motifs dans la langue .
Vous connaissez peut-être les instructions JS
switch. Il est similaire à if-else, mais ses options sont un peu plus limitées, et il est certainement mieux adapté pour organiser le choix de l'une des nombreuses alternatives. Voici à quoi ça ressemble:
switch (value) {
case 1:
// ...
break;
case 2:
// ...
break;
case 3:
// ...
break;
default:
// ...
break;
}
Personnellement, je pense qu'une instruction est
switchplus faible qu'une instruction if, car elle switchne peut comparer ce qui lui est transmis qu'avec des valeurs spécifiques. Cette limitation peut être contournée , mais je ne vois pas pourquoi. De plus, l'instruction est switchsurchargée d'éléments auxiliaires. En particulier, nous parlons d'instructions break.
Le mécanisme de correspondance de modèles peut être considéré comme une version plus fonctionnelle, basée sur des expressions et potentiellement plus polyvalente d'une instruction
switch. Plutôt que de simplement comparer des valeurs, le mécanisme de correspondance de modèles permet au développeur de comparer des valeurs avec des modèles personnalisés (modèles) hautement personnalisables. Voici un extrait de code illustrant un exemple de l'API proposée:
const getLength = vector => case (vector) {
when { x, y, z } -> Math.hypot(x, y, z)
when { x, y } -> Math.hypot(x, y)
when [...etc] -> vector.length
}
getLength({x: 1, y: 2, z: 3})
Il utilise une syntaxe assez inhabituelle pour JavaScript (bien qu'elle soit basée sur la syntaxe trouvée dans des langages tels que Rust ou Scala ), qui présente quelques similitudes avec les instructions que nous connaissons déjà
switch. Ici, au lieu d'un mot-clé, un mot switchest utilisé casequi marque le début du bloc dans lequel la valeur est vérifiée. Puis, à l'intérieur du bloc, en utilisant le mot-cléwhen, nous décrivons les modèles avec lesquels nous voulons valider les valeurs. La syntaxe des modèles ressemble à la syntaxe du mécanisme de déstructuration d'objets déjà disponible dans le langage. Vous pouvez comparer des valeurs à des objets contenant des propriétés sélectionnées, vous pouvez les comparer à des valeurs de propriété sur des objets et à de nombreuses autres entités. Pour en savoir plus sur ce mécanisme, jetez un œil à ce document.
Après la description du modèle, il y a une flèche ("flèche plate",
->) pointant vers l'expression (en perspective - même vers une autre valeur), qui doit être évaluée lors de la recherche d'une correspondance avec le modèle.
Je crois que la présence de telles capacités dans JS nous permettra d'écrire, pour ainsi dire, du code de nouvelle génération. Cependant, la syntaxe proposée me semble maintenant un peu lourde, car elle introduit de nombreuses constructions complètement nouvelles dans le langage. Et le fait que cette proposition en soit encore à la 1ère étape de l'accord me fait penser qu'elle peut encore être améliorée. Cette fonctionnalité semble très prometteuse, mais elle a encore un long chemin à parcourir avant de faire partie de la spécification officielle JS.
Résultat
Ceci conclut mon histoire sur les fonctionnalités révolutionnaires de JavaScript, que nous pourrions voir dans le langage à l'avenir. Il existe d'autres possibilités similaires, par exemple, des propositions pour une bibliothèque standard externe et un opérateur en pipeline . Mais je n'ai choisi pour ce matériau que ce qui me paraissait le plus intéressant. Gardez à l'esprit que ces opportunités sont encore au stade de la proposition. Ils peuvent changer avec le temps. Ou il peut arriver qu'ils n'entrent jamais dans la norme. Mais si, dans tous les cas, vous voulez faire partie de ceux qui utilisent ces opportunités avant les autres, je vous conseille de regarder de plus près des projets comme Babel... Ces projets donnent naissance à de nombreuses phrases JS (notamment celles liées à la syntaxe). Cela permet à quiconque d'expérimenter les dernières fonctionnalités bien avant qu'elles n'apparaissent dans les implémentations de langage.
Quelles sont les fonctionnalités qui vous manquent le plus dans JavaScript?
