# П13 · 2019-03 · Event loop и async-поведение

Статус: **принят в публикационный слой 31 июля 2026 года**. Registry
применяет ревизии по стабильному slug и не заменяет дату или автора базовой
публикации. Внутри пакета три стабильных slug:

- `editorial-2019-03-practice-event-loop`;
- `editorial-2019-03-mechanism-event-loop`;
- `editorial-2019-03-field-event-loop`.

## Граница материала

- Голос: М2, март 2019 года. Автор уже уверенно разбирает JavaScript-сборку и
  границы модулей, но не выдаёт современную observability-платформу за опыт того
  периода. Речь прагматична: симптом → причина → проверка → действие.
- Практика учит поставить минимальный опыт для относительного порядка sync,
  Promise и timer, а затем отдельно измерить синхронную блокировку.
- Механизм разделяет ECMAScript Jobs, browser task и microtask checkpoint. Он
  не обещает одинаковый порядок между разными источниками задач и не называет
  `await` перерывом на отрисовку.
- Полевой разбор разделяет два независимых дефекта: устаревший async-результат
  и CPU/DOM-работу на main thread. Сценарий учебный; результатов реального
  продукта, замеров и конкретного профиля здесь нет.
- Визуальные активы: `event-loop-order-2019.svg`,
  `event-loop-frame-budget-2019.svg`, `event-loop-trace-2019.svg`.

## Pass 1 — факты и техника

- Сверены первичные/официальные источники: HTML Standard для event loop и
  microtask checkpoint, ECMAScript для Jobs и host hook Promise-реакций, W3C
  High Resolution Time для `performance.now()`, W3C Long Tasks API для связи
  длинной работы на UI-потоке с задержкой input и рендеринга.
- Формулировки намеренно разделяют язык и браузер: Promise Job не назван
  «вторым потоком», а browser task не обещает точный момент запуска.
- Для `setTimeout(fn, 0)` записано корректное ограничение: это будущая задача
  после доступности таймера, а не команда выполнить функцию немедленно или
  гарантировать кадр.
- В примерах нет выданных за факт benchmark-результатов. Код показывает метод
  измерения и ожидаемый относительный порядок; его числа зависят от окружения.
- Полевой пример не говорит, что Promise упорядочивает независимые сетевые
  ответы. Актуальность контролируется явным `runId`; отмена названа отдельной
  политикой проекта.
- Ветви решения разделены: явная Promise-зависимость для данных, ограниченные
  порции/алгоритм/worker для CPU-работы, trace для проверки владельца времени.
- Вердикт: фактическая модель соответствует источникам и не скрывает границы.

## Pass 2 — редактура и голос

- В каждом тексте первые абзацы называют наблюдаемый сбой и цену ошибочной
  правки: ложный порядок callback, зависший input или старый результат на
  экране.
- Основная композиция сохраняет маршрут «симптом → причина → проверка →
  действие». Термины `stack`, `microtask`, `task`, `trace`, `runId` появляются
  рядом с проверяемым объектом, а не как украшение.
- Убраны обещания «Promise ускорит код», «таймер гарантирует кадр» и
  «одна очередь объясняет всё». В конце каждого текста указаны ограничения.
- Тон остаётся уровнем М2: автор работает с Console, DevTools и небольшими
  адаптерами, а не приписывает себе поздние практики SLO-платформы или
  наблюдаемости 2025–2027 годов.
- Объём рассчитан как основной прозаический текст без кода, таблиц, рисунков
  и источников; граница 5 000–15 000 знаков проверяется модулем при импорте.
- Вердикт: техническая речь краткая и предметная, без общих рекламных фраз.

## Pass 3 — визуал и выпуск

- У каждой статьи собственная SVG-схема с содержательным alt и подписью:
  порядок stack/microtask/task; длинная работа на main thread; маршрут
  диагностики от лога к действию.
- Во всех трёх статьях есть доступная таблица с `thead` и `scope="col"`,
  несколько блоков кода, нумерованный план действий и раздел источников с
  официальными ссылками.
- SVG используют локальные пути внутри `web/public/assets/editorial/2019/`;
  скрипт ссылается только на эти три assets.
- Выполнены Node syntax, JSON-only CLI/import-safe проверка, `npm run
  audit:draft`, XML-проверка всех SVG и ручной визуальный просмотр.
- Первый визуальный проход на ширине 375 px выявил слишком мелкие подписи в
  горизонтальных вариантах. Все три SVG перестроены в вертикальную композицию;
  повторный рендер на 375 px подтвердил, что карточки, стрелки и подписи не
  обрезаются и читаются без горизонтальной прокрутки.
- Production build, registry и `articles.json` намеренно находятся вне этого
  пакета и не должны упоминаться как выполненные до отдельной интеграции.
- Вердикт: автономный визуальный и выпускной проход принят. Интеграционный
  ревью остаётся отдельной операцией.

## Фактические проверки

| Проверка | Команда или метод | Результат |
| --- | --- | --- |
| Node syntax | `node --check scripts/upgrade-2019-03.mjs` из `web/` | успешно |
| JSON-only CLI | `node scripts/upgrade-2019-03.mjs --print-revisions` | успешно: stdout распарсен как JSON; export и CLI используют одну ревизию |
| Import-safe и content gate | `npm run audit:draft -- scripts/upgrade-2019-03.mjs` из `web/` | успешно: 9 851, 9 896 и 11 104 знака основного HTML |
| XML | `xmllint --noout public/assets/editorial/2019/event-loop-order-2019.svg public/assets/editorial/2019/event-loop-frame-budget-2019.svg public/assets/editorial/2019/event-loop-trace-2019.svg` из `web/` | успешно |
| Визуал | Sharp-рендер SVG и ручной просмотр на 600 px и 375 px | успешно после вертикальной перестройки |

## Выпусковой вердикт

Пакет прошёл автономный тройной review: фактический/технический, редакторский
и визуально-выпускной. После подключения registry основной редактор повторил
строгий аудит всех трёх slug: 9 851 / 9 896 / 11 104 знака, figure, таблицы,
код, маршрут и источники прошли. <code>npm run build</code> завершился с
кодом 0 и сгенерировал 374 статические страницы.

Выпусковой вердикт: **принят к публикации**. <code>articles.json</code> не
менялся; registry заменяет только редакционные поля по стабильному slug.