39 записей с тегом "ECMAScript"

Предложение Явного управления ресурсами вводит детерминированный подход для явного управления жизненным циклом ресурсов, таких как файловые дескрипторы, сетевые подключения и других. Это предложение вносит следующие дополнения в язык: объявления using и await using, которые автоматически вызывают метод dispose, когда ресурс выходит из области видимости; символы [Symbol.dispose]() и [Symbol.asyncDispose]() для операций очистки; два новых глобальных объекта DisposableStack и AsyncDisposableStack как контейнеры для агрегирования освобождаемых ресурсов; и SuppressedError как новый тип ошибки (содержащий как недавно вызванную ошибку, так и подавленную ошибку), чтобы решить ситуацию, когда ошибка возникает во время освобождения ресурса, что может скрыть существующую ошибку, вызванную основным телом операции или освобождением другого ресурса. Эти дополнения позволяют разработчикам писать более надежный, производительный и поддерживаемый код, предоставляя тонкий контроль над освобождением ресурсов.

Помощники итераторов — это набор новых методов в прототипе итератора, которые облегчают общее использование итераторов. Так как эти вспомогательные методы находятся в прототипе итератора, любой объект, имеющий Iterator.prototype в своей цепочке прототипов (например, итераторы массивов), получит эти методы. В следующих подразделах мы объясним помощников итераторов. Все приведенные примеры работают на странице архива блога, содержащей список публикаций, иллюстрируя, насколько полезны помощники итераторов для поиска и манипуляции публикациями. Вы можете попробовать их на странице блога V8!

Ранее​

V8 реализовал функцию утверждений импорта в версии 9.1. Эта функция позволяет инструкциям импорта модулей включать дополнительную информацию, используя ключевое слово assert. В настоящее время эта дополнительная информация используется для импорта JSON- и CSS-модулей внутри JavaScript-модулей.

JavaScript поддерживает регулярные выражения с ECMAScript 3 (1999). Спустя шестнадцать лет в ES2015 были введены режим Unicode (флаг u), режим липкости (флаг y) и геттер RegExp.prototype.flags. Ещё через три года в ES2018 появились режим dotAll (флаг s), обратные проверки, именованные группы захвата и экранирование свойств символов Unicode. А в ES2020 String.prototype.matchAll упростил работу с регулярными выражениями. Регулярные выражения в JavaScript прошли долгий путь и продолжают совершенствоваться.

Поиск элементов с начала​

Поиск элемента, удовлетворяющего определенному условию в Array, является распространенной задачей и выполняется с помощью методов find и findIndex объектов Array.prototype и прототипов TypedArray. Метод 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`.
}

Или используют библиотеки, которые предоставляют простую версию Object.prototype.hasOwnProperty, такие как has или lodash.has.

С предложением 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 не находит эти унаследованные поля: