В JavaScript регулярно появляются новые возможности, и не про все из них мы вообще узнаём. Так, недавно я познакомилась с using и await using. Мне не довелось их применять на практике, но выглядит это интересно.
Смысл в том, чтобы привязать освобождение ресурса к границам блока. Обычно, если мы открыли файл или установили какое-то соединение, то обязаны не забыть всё это закрыть. Сейчас такой код пишется через try/finally, и выглядит примерно так:
const file = await open('data.txt');
try {
const data = await file.read();
} finally {
await file.close();
}
Здесь важно, что open стоит до try. Если убрать его внутрь блока, переменную придётся объявлять снаружи через let, а в finally добавлять ?., потому что при падении open значения там ещё нет. С await using всё это пропадает:
await using file = await open('data.txt');
const data = await file.read();
Файл закроется при любом выходе из блока: при нормальном завершении, исключении, return, break или continue. Разница здесь не столько в количестве строк, сколько в том, что исчезает целый класс возможностей ошибиться.
Работает это с любым объектом, у которого есть метод Symbol.dispose для using или Symbol.asyncDispose для await using. Стандарт описывает только этот протокол, всё остальное остаётся на рантаймах. При этом переменная, объявленная через using, ведёт себя как const, то есть переприсвоить её нельзя.
С поддержкой ситуация уже вполне боевая. Предложение вошло в стандарт ES2026. Node.js поддерживает синтаксис нативно с 24-й версии, TypeScript — с 5.2. В последних версиях браузеров тоже всё работает.
Но дальше начинаются нюансы, из-за которых этот синтаксис так редко встречается в реальном коде. Самая главная причина в том, что встроенных объектов, реализующих протокол, пока очень немного. В Node есть FileHandle из fs/promises, так что тот самый пример выше работает нативно. Однако несмотря на то, что постепенно появляются новые disposable-объекты, список всё ещё короткий.
В браузерных API встроенных disposable-объектов практически нет. Поэтому на клиенте using — это инструмент для своих объектов, а не для чужих, например:
function observe(el, cb) {
const ro = new ResizeObserver(cb);
ro.observe(el);
return { [Symbol.dispose]: () => ro.disconnect() };
}
Второй нюанс касается сборки. TypeScript понимает синтаксис давно, но при target ниже ES2022 он требует, чтобы Symbol.dispose существовал в рантайме или чтобы использовался полифил.
И третье: в обычном продуктовом коде ресурсов, которые нужно явно освобождать, не так уж и много. На фронтенде большая часть работы — это данные и рендер, а там их чистит сборщик мусора. На бэкенде файлы и соединения обычно уже спрятаны внутрь библиотек, которые закрывают всё сами. Так что реальные кейсы для применения — это скрипты, утилиты и собственные абстракции над ресурсами.
Поэтому лично мой вывод: вещь полезная, но не универсальная. Её стоит держать в голове, но области применения пока ограничены.
Смысл в том, чтобы привязать освобождение ресурса к границам блока. Обычно, если мы открыли файл или установили какое-то соединение, то обязаны не забыть всё это закрыть. Сейчас такой код пишется через try/finally, и выглядит примерно так:
const file = await open('data.txt');
try {
const data = await file.read();
} finally {
await file.close();
}
Здесь важно, что open стоит до try. Если убрать его внутрь блока, переменную придётся объявлять снаружи через let, а в finally добавлять ?., потому что при падении open значения там ещё нет. С await using всё это пропадает:
await using file = await open('data.txt');
const data = await file.read();
Файл закроется при любом выходе из блока: при нормальном завершении, исключении, return, break или continue. Разница здесь не столько в количестве строк, сколько в том, что исчезает целый класс возможностей ошибиться.
Работает это с любым объектом, у которого есть метод Symbol.dispose для using или Symbol.asyncDispose для await using. Стандарт описывает только этот протокол, всё остальное остаётся на рантаймах. При этом переменная, объявленная через using, ведёт себя как const, то есть переприсвоить её нельзя.
С поддержкой ситуация уже вполне боевая. Предложение вошло в стандарт ES2026. Node.js поддерживает синтаксис нативно с 24-й версии, TypeScript — с 5.2. В последних версиях браузеров тоже всё работает.
Но дальше начинаются нюансы, из-за которых этот синтаксис так редко встречается в реальном коде. Самая главная причина в том, что встроенных объектов, реализующих протокол, пока очень немного. В Node есть FileHandle из fs/promises, так что тот самый пример выше работает нативно. Однако несмотря на то, что постепенно появляются новые disposable-объекты, список всё ещё короткий.
В браузерных API встроенных disposable-объектов практически нет. Поэтому на клиенте using — это инструмент для своих объектов, а не для чужих, например:
function observe(el, cb) {
const ro = new ResizeObserver(cb);
ro.observe(el);
return { [Symbol.dispose]: () => ro.disconnect() };
}
Второй нюанс касается сборки. TypeScript понимает синтаксис давно, но при target ниже ES2022 он требует, чтобы Symbol.dispose существовал в рантайме или чтобы использовался полифил.
И третье: в обычном продуктовом коде ресурсов, которые нужно явно освобождать, не так уж и много. На фронтенде большая часть работы — это данные и рендер, а там их чистит сборщик мусора. На бэкенде файлы и соединения обычно уже спрятаны внутрь библиотек, которые закрывают всё сами. Так что реальные кейсы для применения — это скрипты, утилиты и собственные абстракции над ресурсами.
Поэтому лично мой вывод: вещь полезная, но не универсальная. Её стоит держать в голове, но области применения пока ограничены.