ECMAScript 2026 без кортежей и записей: новые подходы

[hannadev]

На протяжении нескольких лет разработчики JavaScript ждали появления Records и Tuples - новых структур данных для работы с неизменяемыми значениями. Эти типы обещали упростить работу с данными и сделать код более предсказуемым. Однако в апреле 2025 года TC39 принял решение снять предложение с рассмотрения, оставив сообщество без долгожданной функции.

Это решение стало шоком для многих, но на самом деле оно открывает новые возможности для разработки. Вместо того чтобы ждать встроенной поддержки, разработчики начали активнее использовать альтернативные подходы, которые давно существуют в экосистеме JavaScript. Давайте разберёмся, что произошло и как адаптироваться к новой реальности.

Почему Records и Tuples были отозваны

Всё началось в 2022 году, когда TC39 предложила добавить в ECMAScript два новых примитивных типа данных. Records выглядели как неизменяемые объекты, создаваемые синтаксисом #{}, а Tuples - как неизменяемые массивы с синтаксисом #[]. Идея звучала привлекательно: глубокая неизменяемость, сравнение по значению вместо по ссылке, лучшая производительность в отладчиках.

Но чем больше работала группа стандартизации, тем яснее становилась проблема. Добавление двух новых фундаментальных типов означало изменение самого ядра JavaScript движков. Это не просто создание нового класса или API - это влияние на то, как JavaScript интерпретирует и обрабатывает типы данных повсюду.

Главные причины отзыва предложения:

• Сложность реализации в движках: Новые примитивные типы требуют изменений в логике преобразования типов, что может привести к замедлению даже кода, не использующего Records и Tuples
• Проблема с семантикой равенства: Предложение вводило пятое определение равенства в JavaScript (=== на основе значений для этих типов против сравнения по ссылке для других), что нарушало долгую традицию консистентности
• Недостаточная поддержка сообщества: Хотя идея была интересной, не все согласились, что преимущества оправдывают добавленную сложность

Существующие решения для неизменяемости

Хорошая новость в том, что JavaScript экосистема уже давно предлагает отличные инструменты для работы с неизменяемыми данными. Несколько лет назад это было основной болью разработчиков, и сообщество ответило на неё множеством библиотек и подходов.

Прежде всего, это Immutable.js - одна из самых популярных и зрелых библиотек для работы с неизменяемыми структурами. Она предлагает свои версии Map, List, Set и других структур данных, которые гарантируют полную неизменяемость. Хотя синтаксис немного отличается от встроенных объектов, библиотека очень надёжна и используется в крупных проектах.

Другой мощный инструмент - это функциональные подходы с использованием встроенных методов для создания новых объектов и массивов вместо их модификации. С появлением spread-оператора ... и методов вроде map, filter и reduce стало намного удобнее писать функциональный JavaScript без дополнительных библиотек.

Сравнение основных подходов:

Подход	Плюсы	Минусы	Когда использовать
Immutable.js	Полная гарантия неизменяемости, оптимизация производительности, богатый API	Дополнительная зависимость, другой синтаксис, кривая обучения	Крупные приложения с интенсивной работой с данными
Spread-оператор и встроенные методы	Нет зависимостей, стандартный JavaScript, простой синтаксис	Нужно помнить о чистоте функций, меньше оптимизаций	Типовые приложения, где неизменяемость не критична
Immer	Удобный API через черновики (drafts), объединяет лучшее из двух миров	Ещё одна зависимость, некоторая магия под капотом	Когда нужны удобство и гибкость одновременно
Object.freeze и Object.seal	Встроено в язык, не требует зависимостей	Поверхностная замораживание, низкая производительность	Быстрые прототипы и простые случаи

Практические подходы к адаптации

Теперь, когда понятно, что встроенной поддержки не будет, разработчики должны выбрать стратегию. Это не означает, что проблема неизменяемости остаётся нерешённой - это просто означает, что решение находится в пользовательском коде, а не в самом языке.

Первый подход - осознанно использовать функциональные паттерны. Вместо того чтобы полагаться на встроенные типы, разработчик пишет функции, которые возвращают новые объекты вместо изменения существующих. Например, вместо прямого изменения состояния в Redux или других хранилищах, используются редьюсеры, которые возвращают новое состояние. Этот подход работает хорошо и не требует дополнительных зависимостей.

Второй подход - выбрать подходящую библиотеку. Для проектов, где неизменяемость критична, стоит рассмотреть Immutable.js или более лёгкий вариант, например Immer. Immer особенно интересна, потому что позволяет писать код, который выглядит как изменение объекта, но на самом деле создаёт новые структуры. Это лучшее из двух миров - удобство и безопасность.

Третий подход - использовать TypeScript и типизацию. Когда язык не гарантирует неизменяемость в рантайме, типизация помогает гарантировать её на этапе разработки. С помощью readonly модификатора и утилит вроде DeepReadonly можно заставить TypeScript проверять, что вы не пытаетесь изменить данные.

Практические шаги для вашего проекта:

1. Оцените, где нужна неизменяемость: Не в каждой части кода она критична. Сосредоточьтесь на местах, где это действительно важно - глобальное состояние, логика бизнеса, обработчики событий
2. Выберите инструмент: Если используете Redux, Zustand или MobX, они уже предлагают рекомендации по неизменяемым обновлениям. Если нужна универсальная библиотека, присмотритесь к Immer
3. Документируйте соглашения: Договоритесь в команде, какие данные считаются неизменяемыми и как их обрабатывать
4. Используйте lintery правила: ESLint плагины вроде eslint-plugin-immutable помогут поймать случайные мутации

TypeScript как частичное решение

Особая роль в адаптации принадлежит TypeScript. Хотя он не даёт реальной неизменяемости в рантайме, он может очень хорошо имитировать её на этапе разработки. С помощью readonly ключевого слова и утилит вроде Readonly<T> и DeepReadonly<T> можно создать очень строгие ограничения на то, как обрабатываются данные.

Это особенно полезно, потому что TypeScript не требует дополнительных зависимостей и работает с обычными объектами и массивами JavaScript. Разработчик может писать код, как обычно, но типизация гарантирует, что он не попадёт в ловушку случайного изменения данных.

Когда стоит полагаться на TypeScript для неизменяемости:

• Ваш проект уже использует TypeScript
• Нужна лёгкая защита без библиотек
• Команда готова следовать соглашениям типизации
• Рантайм неизменяемость не критична (например, нет контактов с недоверенным кодом)

Что дальше для экосистемы

Отзыв Records и Tuples - это не конец истории про неизменяемость в JavaScript, а новый виток развития. TC39 продолжит искать способы улучшить язык, но учтёт уроки из этой попытки. Возможно, в будущем появятся другие предложения, которые достигнут лучшего баланса между удобством и сложностью реализации.

В ближайшее время разработчикам стоит сосредоточиться на максимальном использовании существующих инструментов. Функциональное программирование, TypeScript типизация и проверенные библиотеки вроде Immutable.js и Immer предлагают очень мощный набор решений для работы с неизменяемыми данными. Экосистема JavaScript продолжит развиваться, и каждый разработчик найдёт подходящий для себя уровень защиты от случайных мутаций данных.