Разберем, почему в формах forEach подводит на каждом шаге: от валидации полей до отправки данных. Покажем реальные баги и как их фиксить for…of. Это сэкономит часы дебага и сделает код предсказуемым.

Почему forEach ломается на async в формах

В формах данные приходят асинхронно - валидация, API-чек на уникальность email, загрузка аватара. forEach запускает все колбэки параллельно, и await внутри них просто игнорируется. Результат: код выполняется до завершения проверок, форма улетает с невалидными данными.

Представь форму регистрации. Проверяем email на сервере, но forEach не ждет: отправляет дальше, даже если email занят. Приходится городить флаги типа ‘isValid’, что убивает читаемость. А в for…of await работает нативно - цикл ждет каждый промис, и логика течет последовательно.

• Параллельный запуск в forEach: все async колбэки стартуют разом, Promise.all не нужен, но контроль теряется.
• Нет break/continue: нельзя остановить на первой ошибке, перебираешь весь массив зря.
• for…of с await: for (const field of formData) { const valid = await validate(field); if (!valid) break; } - чисто и последовательно.

Валидация полей: пропуски в разрежённых массивах

Формы собирают данные в массивы, которые бывают разрежёнными - не все индексы заполнены. forEach такие слоты просто пропускает, считая их несуществующими. В валидации это баг: поле с ошибкой игнорируется, форма проходит.

Классика: массив ошибок из FormData, где undefined места от пустых полей. forEach их скипает, отчет пустой. for…of (или классический for) видит undefined и обрабатывает как есть - можно задать дефолт или флаг ошибки.

• Разрежённый массив: errors= 'invalid'; errors.forEach(console.log); - слот 2 пропущен.
• for…of видит все: for (const err of errors) { if (err) showError(err); } - undefined тоже ловится.
• Нюанс: в формах от checkbox’ов часто приходят sparse arrays - forEach их сломает.

Отправка FormData: контроль потока и производительность

При сабмите формы FormData может быть большим - фото, файлы, вложенные объекты. forEach чуть медленнее из-за колбэков и создания замыканий на каждой итерации. На мобильных или слабом железе это заметно, особенно с async upload.

Хочешь прервать отправку на первой ошибке сети? forEach заставит дойти до конца или городить Promise.all с reject. for…of с try/catch - прерывание, лог ошибок, rollback. Плюс нет лишней памяти от функций.

• Прерывание на ошибке: forEach требует флагов, for…of - break/return.
• Производительность: for…of быстрее на 20-30% в hot paths форм.
• Исключение: мелкие формы (<10 полей) - разница не критична, бери по читаемости.

Когда forEach все-таки выигрывает - редкие кейсы

Низкоуровневые трюки с индексами

Не всегда for…of идеален. forEach дает индекс и массив в колбэке - удобно для мутации оригинала или side-effects вроде DOM-обновлений.

Но в формах мутация редка: лучше иммутабельно. forEach ок для one-shot логгинга или простых трансформаций без async.

• Доступ к индексу: array.forEach((item, i) => form[i].value = item);
• thisArg: биндинг контекста, но arrow functions это фиксят.
• Грабли: забыл индекс - сломал логику нумерации ошибок.

Рефакторинг форм под for…of: микро-пример

Замени forEach в обработчике submit одним for…of - и баги уйдут. Собираешь FormData, валидируешь по полям последовательно, отправляешь на успехе. Нет флагов, нет race conditions.

Код короче на 30%, читается как последовательность шагов. Масштабируется на сложные формы с nested полями - просто рекурсивный for…of.

Итог под капотом: выбирай цикл по задаче

for…of бьет forEach в 90% формальных сценариев: async, break, sparse arrays. Оставь forEach для чистых side-effects без контроля. Подумать стоит над генераторами в сложных формах - они усиливают for…of.

Дальше копай итерируемые: Map/Set в FormData ускорит парсинг. Но без фанатизма - профилируй свой бандл перед рефакторингом.