Перестаньте всё превращать в массивы (и работайте меньше)

Большая часть фронтенд-кода обрабатывает данные задолго до их вывода на экран. Мы получаем список, изменяем его, сокращаем и повторяем. И обычно не задумываемся о том, какой объём работы выполняем на этом пути.

Уже много лет современный JavaScript подталкивает нас к знакомому шаблону:

	
data
  .map(...)
  .filter(...)
  .slice(...)
  .map(...)
	

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

Помощники итераторов (Iterator helpers) в JavaScript предоставляют нам встроенную, ленивую (lazy) альтернативу, которая особенно актуальна для работы с большими наборами данных, потоками и логикой, управляемой пользовательским интерфейсом.

Массивы везде и всюду (куча лишней работы)

Рассмотрим такой сценарий интерфейса:

• Вы получаете большой набор данных
• Вы фильтруете его
• Вы берете первые несколько результатов
• Вы отображаете их

	
const visibleItems = items
  .filter(isVisible)
  .map(transform)
  .slice(0, 10);
	

Выглядит безобидно, верно? Я писал именно такую цепочку чаще, чем готов признать. Под капотом происходит вот что:

1. filter создаёт новый массив.
2. map создаёт ещё один массив.
3. slice создаёт очередной массив.

Даже если вам нужно всего 10 элементов, вы, возможно, обработали тысячи. В этом несоответствии — вся суть проблемы. И именно здесь итераторы (iterator helpers) окупаются.

Итак, что такое вспомогательные методы итераторов?

Это цепочные методы для объектов-итераторов, а не для массивов.

Это различие важно. И да, это легко упустить из виду вначале: у массивов волшебным образом не появляются эти методы. Вам нужен итератор из values(), keys(), entries() или генератора. И тогда вы можете построить на его основе ленивый конвейер.

Они позволяют вам делать такие вещи, как:

• map
• filter
• take
• drop
• flatMap
• find, some, every
• reduce
• toArray

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

Примечание: В отличие от других, метод reduce активно (жадно) потребляет итератор, так как для получения результата он должен обработать каждое значение.

В общем случае, ленивость подразумевает:

• Отсутствие промежуточных массивов
• Отсутствие лишней работы
• Что важнее всего, вычисления останавливаются, как только это становится возможным

Вы описываете желаемый результат, а среда выполнения извлекает значения только тогда, когда они нужны.

По умолчанию ленивый (Lazy by default)

Вот та же логика с помощниками итератора (iterator helpers):

	
const visibleItems = items
  .values()
  .filter(isVisible)
  .map(transform)
  .take(10)
  .toArray();
	

Так что же здесь действительно изменилось?

• items.values() возвращает итератор, а не массив
• Каждый шаг выполняется только при запросе следующего значения
• Обработка останавливается после 10 совпадений

Что это даёт в реальных приложениях

Дело не только в чистой производительности, а в избегании лишней работы. Помощники итераторов открывают доступ к более эффективным паттернам построения UI.

Рендеринг больших списков

Если вы работаете с:

• Виртуализированными списками
• Бесконечной прокруткой
• Крупными таблицами

Ленивая итерация означает, что вы не обрабатываете элементы, которые никогда не отображаются на экране.

	
function* rows(data) {
  for (const row of data) {
    yield renderRow(row);
  }
}

const visibleRows = rows(data)
  .filter(isInViewport)
  .take(20)
  .toArray();
	

Этот принцип часто связан с эффективным рендерингом в JavaScript-библиотеках (например, React), где целью является обновление только тех частей интерфейса, которые изменились, избегая лишних вычислений и манипуляций с DOM для максимальной производительности.

Потоковая передача и асинхронные данные

Асинхронные итерируемые объекты обладают собственными вспомогательными методами (iterator helpers), что делает их отлично подходящими для работы с постраничными API и потоками данных.

	
async function* fetchPages() {
  let page = 1;
  while (true) {
    const res = await fetch(`/api/items?page=${page++}`);
    if (!res.ok) return;
    yield* await res.json();
  }
}

const firstTen = await fetchPages()
  .filter(isValid)
  .take(10)
  .toArray();
	

Никакого буферизирования полных ответов, никаких ручных счётчиков. Просто опишите конвейер (пайплайн) и позвольте среде выполнения (рантайму) вытягивать данные по мере необходимости.

Более чистые конвейеры данных (без библиотек утилит)

Раньше, до появления помощников итераторов, вам приходилось использовать сторонние библиотеки для реализации ленивых конвейеров. Теперь это встроено в язык:

	
const ids = users
  .values()
  .map(u => u.id)
  .filter(Boolean)
  .toArray();
	

Читаемый, нативный, без зависимостей.

Помощники итераторов против методов массивов

Правило большого пальца: если вам не нужен весь массив — не создавайте его.

Когда не стоит использовать помощники итераторов

Помощники итераторов — мощный инструмент, но они не могут и не должны везде заменять массивы. Если пытаться втиснуть их в каждую ситуацию, это только ухудшит читаемость кода. Они плохо подходят, когда:

• Вам нужен произвольный доступ (например, items[5]).
• Вы сильно полагаетесь на изменение (мутацию) массива.
• Ваш объём данных невелик, и важнее простота решения.

Подводные камни, о которых стоит знать

Вспомогательные методы итераторов работают иначе, чем массивы, в нескольких ключевых аспектах. Если данных немного, лучше выбрать простой подход.

Думайте об итераторах как о работе, которая ещё не выполнена, а не как о данных, которые у вас уже есть.

Могу ли я использовать это уже сегодня?

Помощники итераторов поддерживаются во всех современных браузерах и в Node.js 22+. Если ваша целевая среда — что-то актуальное, проблем не будет.

Сознательное уменьшение работы

Долгое время JavaScript приучал нас сразу превращать всё в массивы. Помощники итераторов дают альтернативу:

• Выполнять меньше операций
• Выделять меньше памяти
• Создавать цепочки обработки, которые соответствуют реальному поведению интерфейсов

И как только вы привыкнете к ленивой итерации, возврат к "жадным" цепочкам кажется уже несколько расточительным.