「ECMAScript」タグの記事が39件件あります

明示的リソース管理(Explicit Resource Management)提案は、ファイルハンドル、ネットワーク接続などのリソースのライフサイクルを明示的に管理するための決定的なアプローチを導入します。この提案により、次の言語拡張が行われます：スコープ外になったリソースで自動的にdisposeメソッドを呼び出すusingとawait using宣言、クリーンアップ操作のための[Symbol.dispose]()および[Symbol.asyncDispose]()シンボル、破棄可能なリソースを集約するコンテナとしての新しいグローバルオブジェクトDisposableStackとAsyncDisposableStack、リソースの破棄中にエラーが発生し、ボディや別のリソースから発生した既存のエラーを潜在的にマスクするシナリオに対応するための新しいエラータイプSuppressedError。これにより、リソースの破棄を細かく制御できるため、より堅牢でパフォーマンスに優れた、メンテナンスが容易なコードを記述することが可能になります。

イテレーター ヘルパーは、イテレーターの一般的な使用を助けるためのIteratorプロトタイプ上の新しいメソッド群です。これらのヘルパーメソッドはIteratorプロトタイプ上にあるため、プロトタイプチェーン上にIterator.prototypeを持つ任意のオブジェクト（例えば配列イテレーター）はこれらのメソッドを利用できます。以下のサブセクションでは、イテレーター ヘルパーについて説明します。提供されているすべての例はブログ投稿のリストを含むアーカイブページで機能し、投稿の検索や操作にイテレーター ヘルパーがどのように役立つかを示しています。V8ブログページで試してみてください！

以前は​

V8はv9.1でインポートアサーション機能を提供しました。この機能により、モジュールインポート文にassertキーワードを使用して追加情報を含めることが可能になりました。この追加情報は現在、JavaScriptモジュール内でJSONやCSSモジュールをインポートするために使用されています。

JavaScript は ECMAScript 3 (1999) 以来、正規表現をサポートしています。16 年後、ES2015 は Unicode モード (u フラグ)、スティッキーモード (y フラグ)、および RegExp.prototype.flags エッター を導入しました。そのさらに 3 年後、ES2018 は dotAll モード (s フラグ)、後読みアサーション、名前付きキャプチャグループ、および Unicode 文字プロパティエスケープ を導入しました。そして ES2020 では、String.prototype.matchAll により正規表現の操作がさらに簡単になりました。JavaScript の正規表現は大きく進化しており、現在も進化中です。

配列の最初から要素を検索する​

Array 内で条件を満たす要素を検索することは一般的なタスクであり、Array.prototype または様々な TypedArray プロトタイプ上で利用できる find および findIndex メソッドで行います。Array.prototype.find は述語を受け取り、その述語が true を返す最初の要素を配列から返します。述語がどの要素に対しても true を返さない場合、このメソッドは undefined を返します。

新しいatメソッドは、Array.prototype、各種TypedArrayプロトタイプ、そしてString.prototypeに追加され、コレクションの末尾付近にある要素に簡潔かつ簡単にアクセスできるようになります。

コレクションの末尾からN番目の要素にアクセスすることは一般的な操作です。しかし、通常の方法では冗長で、たとえばmy_array[my_array.length - N]のような記述になったり、my_array.slice(-N)[0]のようにパフォーマンスが適切でない場合があります。新しいatメソッドは負のインデックスを「末尾から」と解釈することで、この操作をより快適にします。上記の例はmy_array.at(-N)と表現できます。

例えば、doSomeWork と doMoreWork という2つの異なる作業を呼び出す関数があるとします。この2つの関数は同じ種類のエラーを投げる可能性がありますが、それらを別々に処理する必要があります。

エラーをキャッチし、それに追加のコンテキスト情報を付加して再スローすることは、この問題に対処する一般的な方法です。例えば以下のように:

function doWork() {
  try {
    doSomeWork();
  } catch (err) {
    throw new CustomError('作業の一部が失敗しました', err);
  }
  doMoreWork();
}

try {
  doWork();
} catch (err) {
  // |err| は |doSomeWork| または |doMoreWork| のどちらから来たのか？
}

残念ながら、上記の解決法は手間がかかります。なぜなら、自分で CustomError を作成する必要があるからです。さらに悪いことに、開発ツールが予期しない例外に対して有益な診断メッセージを提供することができません。これは、これらのエラーを正しく表現する方法についての合意がないためです。

今日では、次のようなコードを書くことが非常に一般的です。

const hasOwnProperty = Object.prototype.hasOwnProperty;

if (hasOwnProperty.call(object, 'foo')) {
  // `object`にはプロパティ`foo`があります。
}

また、hasやlodash.hasのように、Object.prototype.hasOwnPropertyの簡易版を提供するライブラリを使用することもあります。

Object.hasOwn提案を使用することで、次のように簡単に記述できます。

if (Object.hasOwn(object, 'foo')) {
  // `object`にはプロパティ`foo`があります。
}

Object.hasOwnは既にV8 v9.3で--harmony-object-has-ownフラグを使用して利用可能であり、間もなくChromeでも導入される予定です。

Object.hasOwn対応状況​

新しいインポートアサーション機能により、モジュール指定子とともに追加の情報をインポート文に含めることができます。この機能の初期の用途として、JSON文書をJSONモジュールとしてインポート可能にすることがあります:

in演算子は、与えられたオブジェクト（またはそのプロトタイプチェーン内の任意のオブジェクト）が与えられたプロパティを持っているかどうかを確認するために使用できます:

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

プライベートブランドチェック機能は、このin演算子を拡張してプライベートクラスフィールドもサポートします:

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; 同じ#fooではない

プライベート名はそれを定義するクラスの内部でのみ利用可能であるため、テストは上記のstatic testのようなメソッド内など、クラス内部で行う必要があります。

サブクラスのインスタンスは、親クラスからプライベートフィールドを自身のプロパティとして受け取ります:

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

しかし、Object.createで作成されたオブジェクトや、その後に__proto__セッターやObject.setPrototypeOfを使用してプロトタイプが設定されたオブジェクトは、プライベートフィールドを自身のプロパティとして受け取りません。プライベートフィールドの検索は自身のプロパティに対してのみ機能するため、in演算子はこれらの継承されたフィールドを見つけることができません: