"ECMAScript" 태그로 연결된 39개 게시물개의 게시물이 있습니다.

명시적 리소스 관리 제안은 파일 핸들, 네트워크 연결 등과 같은 리소스의 수명 주기를 명시적으로 관리하기 위한 결정론적 접근 방식을 도입합니다. 이 제안은 다음과 같은 언어 추가 사항을 포함합니다: using 및 await using 선언은 리소스가 범위를 벗어날 때 자동으로 dispose 메서드를 호출합니다. [Symbol.dispose]() 및 [Symbol.asyncDispose]() 심볼은 정리 작업용입니다. 두 개의 새로운 글로벌 객체 DisposableStack 및 AsyncDisposableStack은 폐기 가능한 리소스를 집계하기 위한 컨테이너로 제공되며, SuppressedError는 리소스 폐기 중 오류가 발생하고 기존 오류가 마스킹되는 시나리오를 해결하기 위한 새로운 유형의 오류로 (최근에 발생한 오류와 억제된 오류 모두를 포함) 도입되었습니다. 이러한 추가 사항은 리소스 폐기에 대한 세밀한 제어를 제공하여 개발자가 더욱 견고하고 성능이 뛰어나며 유지 관리가 용이한 코드를 작성할 수 있도록 합니다.

반복자 도우미는 반복자를 일반적으로 사용하는 데 도움을 주는 Iterator 프로토타입에 대한 새로운 메서드 모음입니다. 이 도우미 메서드들은 반복자 프로토타입에 있기 때문에, 프로토타입 체인에 Iterator.prototype을 가진 모든 객체(예: 배열 반복자)는 이 메서드들을 사용할 수 있습니다. 다음 단락에서는 반복자 도우미를 설명합니다. 제공된 모든 예시는 블로그 포스팅 목록이 포함된 블로그 아카이브 페이지에서 작동하며, 반복자 도우미가 포스트를 찾고 조작하는 데 어떻게 유용한지 보여줍니다. V8 블로그 페이지에서 시도해 볼 수 있습니다!

이전에​

V8은 v9.1에서 가져오기 어설션 기능을 도입했습니다. 이 기능은 모듈 가져오기 구문에 assert 키워드를 사용하여 추가 정보를 포함할 수 있게 해줍니다. 현재 추가 정보는 JavaScript 모듈 내부에서 JSON 및 CSS 모듈을 가져오는 데 사용됩니다.

JavaScript는 ECMAScript 3 (1999)부터 정규 표현식을 지원했습니다. 16년 후, ES2015는 유니코드 모드 (u 플래그), 스티키 모드 (y 플래그), 그리고 RegExp.prototype.flags 게터를 도입했습니다. 또 3년 뒤, ES2018은 dotAll 모드 (s 플래그), 후행 어설션, 명명된 캡처 그룹 및 유니코드 문자 속성 이스케이프를 도입했습니다. 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를 호출하는 함수를 상상해보세요. 두 함수는 동일한 종류의 오류를 던질 수 있지만, 각각 다른 방식으로 처리해야 합니다.

오류를 잡은 다음 추가적인 컨텍스트 정보를 추가하여 다시 던지는 것은 이 문제에 대한 일반적인 접근 방식입니다. 예를 들어:

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 지원​

새로운 import assertions 기능을 사용하면 모듈 임포트 문에서 모듈 지정자와 함께 추가 정보를 포함할 수 있습니다. 이 기능의 초기 용도는 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 연산자는 이러한 상속된 필드를 찾지 못합니다: