未来からの4つの革新的なJavaScript機能

ECMAScript 6（ES6）標準がリリースされて以来、JavaScriptは急速かつ動的に進化してきました。ECMA-262標準の新しいバージョンが毎年リリースされているという事実のおかげで、そしてすべてのブラウザメーカーの巨大な仕事のおかげで、JSは世界で最も人気のあるプログラミング言語の1つになりました。



最近、ES2020で導入された新機能について書きました..。これらの可能性のいくつかは興味深いものですが、「革命的」と呼ばれるに値するものはありません。最近JS仕様が頻繁に更新されていることを考えると、これは理解できます。標準に取り組んでいる人は、ES6モジュールや矢印関数などの特別なものを言語に絶えず導入する機会が少ないことがわかりました。 しかし、これは、もっぱら新しいものが最終的にその言語で表示されないという意味ではありません。実は、これが今日お話ししたいことです。長期的には革命的と言える4つの可能性についてお話したいと思います。彼らは現在、プロセスのさまざまな段階にあります。







提案の調整。これは、一方ではJavaScriptでそれらを表示できない可能性があることを意味し、他方では、そのような文の存在は、それにもかかわらず、いつかその言語でそれらに会うことを期待しています。

デコレータ

おそらく最も頻繁に言語に含めるように求められ、その周りでかなりの話題が高まっている機能から始めます。数年前、彼らは文字通りどこにでも彼女について書いた。それはデコレータについてです。



あなたはすでにデコレータに精通しているかもしれません。特にTypeScriptで書く場合。これは、本質的に、開発者が独自の機能をクラス、個々のフィールドおよびメソッドに「注入」して、最終的にクラスをプログラム可能にする機能を提供することを目的としたメタプログラミングの概念です。



次の例を見てください。

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;
  }
}

ここでは、慎重に進めることにし、TypeScriptデコレータの使用例を示しました。私は主に一般的な考えを示すためにこれを行いました。上記のコードスニペットでは、デコレータを作成sealedしてクラスに適用しましたGreeter。ご覧のとおり、デコレータは、適用されるクラスのコンストラクタにアクセスできる関数です（これがターゲットです）。コンストラクターへの参照とObject.seal()、クラスを拡張不可能にするメソッドを使用します。



デコレータをクラスに適用する@には、クラス宣言の直前にデコレータの名前をアイコンで書き留めます。その結果、クラス宣言が表示される前に、フォームの構成が表示されることがわかりました。@[name]この場合は、のようになり@sealedます。



オプションを有効にしてこのTSコードをコンパイルしexperimentalDecorators、クラスプロトタイプを変更しようとすると、デコレータの機能を確認できます。

Greeter.prototype.test = "test"; // ERROR

その結果、デコレータが必要な理由を一般的に理解できるようになります。しかし、ここで1つの難しい質問に触れたいと思います。それは装飾者のための提案の承認の状態に関係します。



正当な理由から、TypeScriptを使用してデコレータをデモンストレーションすることにしました。重要なのは、JavaScriptにデコレータを埋め込むという提案が数年前に行われたということです。そして現在、4つのうちの合意の第2段階で「のみ」です。この提案のデコレータの構文と機能の両方が絶えず変更されています。しかし、それはJSコミュニティがこの概念を使用することを妨げるものではありません。これを確信するには、TypeScriptやAngular v2 +などの巨大なオープンソースプロジェクトを検討するだけで十分です。



確かに、これらすべては、時間の経過とともに、提案が発展するにつれて、仕様の非互換性に関連する問題につながります。つまり、デコレータの仕様は、提案が出てから大きく進化しましたが、まだ多くのプロジェクトで実装されていません。上記のTypeScriptの例は、古いバージョンの提案の実装のデモンストレーションです。 Angularについても、Babelについても同じことが言えます（ただし、Babelの場合、この仕様の新しいバージョンを実装するための作業が現在進行中であると言えます）。一般に、decoratorリンクに適したキーワードと構文を使用する新しいバージョンの文は、まだ目立った用途を見つけていません。



肝心なのは、デコレータはコードの書き方を変える可能性があるということです。そして、デコレータはまだ初期段階にありますが、これらの変更はすでに現れています。しかし、現在の状況を考えると、デコレータはコミュニティを断片化しているだけであり、実際に本格的に使用する準備はまだ整っていないと思います。デコレータに興味のある方は、少し待ってから本番環境に導入することをお勧めします。ただし、私の推奨事項は、デコレータ（Angularなど）を使用するフレームワークを使用している場合には適用されません。

レルム

それでは、少し速度を落とし、デコレータほど複雑ではない1つの機能について説明しましょう。私たちは地域について話している。



独自のコードまたはサードパーティの開発者からのコードを実行する必要がある状況にすでに陥っている可能性がありますが、同時に、このコードがグローバル環境に影響を与えないように実行してください。多くのライブラリ、特にブラウザライブラリは、グローバルオブジェクトを介して機能しますwindow。その結果、プロジェクトが開発者の制御を超えて非常に多くのライブラリを使用する場合、それらは互いに干渉する可能性があります。これはエラーにつながる可能性があります。



この問題に対する現在のブラウザの解決策は、要素を使用することです<iframe>、およびいくつかの特別な場合-Webワーカーの使用。 Node.js環境では、モジュールまたは子プロセスvmを使用して同じ問題を解決します。 Realms APIは、このような問題を解決するように設計されています。



このAPIは、開発者がスコープと呼ばれる個別のグローバル環境を作成できるようにすることを目的としています。そのような各領域には、独自のグローバルエンティティがあります。次の例を見てください。

var x = 39;
const realm = new Realm();

realm.globalThis.x; // undefined
realm.globalThis.x = 42; // 42
realm.globalThis.x; // 42

x; // 39

ここではRealm、適切なコンストラクターを使用して新しいオブジェクトを作成します。今後は、プロパティglobalThis（ES2020で導入）を介して新しいスコープとそのグローバルオブジェクトに完全にアクセスできるようになります。ここでは、メインの「インキュベーター」の変数が、作成したスコープ内の変数から分離されていることがわかります。



全体として、Realms APIは非常に単純なメカニズムとして計画されていますが、これは便利なメカニズムです。このAPIには、非常に特殊な一連のユースケースがあります。それは私たちに高レベルのセキュリティ、またはマルチスレッドコードへの機能を提供しません。しかし、システムに不要な負荷をかけることなく、分離された環境を作成するための基本的な機能を提供することで、その主要なタスクに完全に対処します。



Realms APIの提案は、現在交渉の第2段階にあります。最終的に標準に達すると、グローバルスコープに依存する「重い」ライブラリ、オンラインのサンドボックス化されたコードエディタ、さまざまなアプリケーションを対象としたアプリケーションで使用されることが期待されます。テスト。

式を行う

JavaScript構文には、ほとんどのプログラミング言語の構文と同様に、ステートメントと式が含まれています。これらの構成の最も顕著な違いは、式を値として使用できることです（つまり、式を変数に割り当てたり、関数に渡したりすることができます）が、ステートメントはそのように使用できません。



この違いがあるため、よりクリーンでコンパクトなコードを作成するには、式が最も好ましい選択肢です。 JavaScriptでは、矢印関数を含む関数式の人気と、関数宣言、関数ステートメントを比較することで、これを確認できます。配列を反復処理する方法を比較すると、同じ状況が見られます（forEach()）サイクルあり。三元演算子と命令を比較する場合、より高度なプログラマーにも同じことが言えますif。現在交渉段階1にあるdo-expression



提案は、JS式の機能をさらに強化することを目的としています。ちなみに、「do-expression」の概念をループと混同しないでください。ループはまったく異なるものです。 次に例を示します。do…while

let x = do {
  if (foo()) {
    f();
  } else if (bar()) {
    g();
  } else {
    h();
  }
};

do-expression句の構文は次のとおりです。一般に、私たちの前には、構造でラップされたJSコードがありますdo {}。この構成の最後の式は、do式全体の最終値として「返されます」。



同様の（ただし同一ではない）効果は、IIFE（Immediately Invoked Function Expression）を使用して実現できます。しかし、do式の場合、そのコンパクトな構文は非常に魅力的です。ここでは、同様の機能でreturn、、またはのような醜い補助構造は必要ありません(() => {})()..。これが、式が標準に入ると、JavaScriptへの影響が矢印関数の影響に匹敵すると私が信じる理由です。式の便利さとわかりやすい構文、いわば、1つのパッケージで非常に魅力的に見えます。

パターンマッチング

この機会はこの資料の最後ですが、重要性は最後ではありません。これは、言語にパターンマッチングメカニズムを導入することを目的とした提案です。



あなたはJS命令に精通しているかもしれませんswitch。に似てif-elseいますが、そのオプションはもう少し制限されており、多くの選択肢の1つを選択するのに適しています。これはそれがどのように見えるかです：

switch (value) {
  case 1:
    // ...
    break;
  case 2:
    // ...
    break;
  case 3:
    // ...
    break;
  default:
    // ...
    break;
}

個人的には、渡されたものを特定の値としか比較できないので、命令は命令switchよりも弱いと思います。この制限は回避できますが、理由はわかりません。さらに、命令は補助要素で過負荷になっています。特に、指示について話している。 パターンマッチングメカニズムは、ステートメントのより機能的で、式ベースの、潜在的により用途の広いバージョンと考えることができます。単に値を比較するのではなく、パターンマッチングメカニズムにより、開発者は高度にカスタマイズ可能なカスタムパターン（テンプレート）と値を比較できます。提案されたAPIの例を示すコードスニペットを次に示します。ifswitchswitchbreak



switch

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})

これは、JavaScriptでは非常に珍しい構文を使用します（ただし、RustやScalaなどの言語で見られる構文に基づいています）。これは、すでに知られている命令といくつかの類似点がありますswitch。ここでは、キーワードの代わりに、値がチェックされるブロックの開始を示す単語switchが使用されcaseています。次に、ブロック内で、キーワードを使用しますwhen、値を検証するためのテンプレートについて説明します。テンプレートの構文は、その言語ですでに利用可能なオブジェクト破壊メカニズムの構文に似ています。値は、選択したプロパティを含むオブジェクトと比較でき、オブジェクトのプロパティ値や他の多くのエンティティと比較できます。このメカニズムの詳細については、このドキュメントをご覧ください。



テンプレートの説明の後->に、式を指す矢印（「フラット矢印」）があります（遠近法では、別の値でも）。これは、パターンとの一致を見つけるときに評価する必要があります。



JSにそのような機能があれば、いわば新世代のコードを書くことができると思います。ただし、提案された構文は、言語にまったく新しい構造を多数導入するため、私には少し面倒に思えます。そして、この提案がまだ合意の第一段階にあるという事実は、まだ改善の余地があると私は思います。この機能は非常に有望に見えますが、公式のJS仕様に入るまでにはまだ長い道のりがあります。

結果

これで、JavaScriptの革新的な機能についての私の話は終わりです。これは、将来この言語で見られる可能性があります。他にも同様の可能性があります。たとえば、外部標準ライブラリとパイプライン化された演算子の提案です。しかし、私はこの資料のために、私にとって最も興味深いと思われるものだけを選びました。これらの機会はまだ提案段階にあることに留意してください。それらは時間とともに変化する可能性があります。または、彼らが標準に入らないことが起こるかもしれません。しかし、いずれにせよ、そのような機会を他の人よりも先に利用したいのであれば、バベルなどのプロジェクトを詳しく調べることをお勧めします。..。これらのプロジェクトは、多くのJS提案（特に構文に関連する提案）を生み出します。これにより、言語の実装に表示されるずっと前に、誰でも最新の機能を試すことができます。



JavaScriptで最も見逃している機能は何ですか？