State-баги, которые ловит только запуск

Урок 5 сказал: «зелёный tsc ≠ работает». Этот урок объясняет почему — на двух настоящих багах из среза питания. Оба прошли типы. Оба поймал только живой драйв. И — сюрприз — второй баг родил фикс первого. Ты не пишешь код, но должен знать, где именно у экрана появляется невидимая для типов дыра.

1 · Баг первый: инициализатор сработал один раз — до данных

Карточка питания предзаполняет поля сегодняшней записью. Первая версия читала запись прямо в инициализаторе состояния:

const todayEntry = log.find(e => e.date === today);
const [fields, setFields] = useState({
  protein: todayEntry?.protein ?? '',   // ← читается ОДИН раз
  ...
});

2 · Баг второй: фикс первого создал гонку

Первый фикс выглядел очевидным: раз инициализатор бежит рано — перезаполним поля в useEffect, когда log подгрузится.

useEffect(() => {
  if (!todayEntry) return;
  setFields({ protein: String(todayEntry.protein), ... });
}, [todayEntry]);   // ← бежит, КОГДА данные пришли

const hydratedRef = useRef(false); // уже заполнили из сервера?
const dirtyRef = useRef(false);    // юзер начал печатать?

useEffect(() => {
  if (hydratedRef.current || dirtyRef.current || !todayEntry) return;
  hydratedRef.current = true;
  setFields({ ... });
}, [todayEntry]);
// onChange: dirtyRef.current = true; setFields(...)

Мораль, которую ты уже сформулировал в уроке 5: фикс — это тоже изменение, его надо перепроверять запуском. Первый фикс закрыл видимый баг и тихо открыл гонку. Зелёный tsc после фикса не значит ничего: типы одинаково довольны и багом, и лекарством, и лекарством с новым багом.

3 · Почему у этого класса нет типа — и как его ловить

Оба бага — из одного семейства: гонка асинхронной загрузки и локального состояния. Форма данных всё время корректна; ломается порядок. У порядка событий нет статического типа, поэтому инструмент, который смотрит на застывший снимок (типы, чтение диффа глазами), его пропустит by design.

1. Сохранил → перезагрузил → поле предзаполнено (не пусто).
2. Начал печатать ДО загрузки → мой ввод не затёрт данными.

Проверь себя

Упражнение — предскажи баг по описанию

Я даю тебе описание будущего среза. Не читая кода, назови тайминг-сценарий, который надо потребовать в приёмке, и класс бага, который он ловит.

1. Срез А. «Экран профиля предзаполняет имя пользователя из /api/auth/me и даёт его отредактировать». Какой тайминг-сценарий обязателен? Какой баг он ловит?
2. Срез Б. «Список сообщений подгружается, поле ответа предзаполнено черновиком из localStorage». Где здесь возможна гонка загрузка-vs-ввод?
3. Правило. Сформулируй одним предложением, когда форму с предзаполнением обязательно гонять драйвом со временем, а не просто «открыл и посмотрел».

Бонус — поймай слабое доказательство. Ниже отчёт агента. Найди дыру до того, как раскроешь.

Что уносишь

Есть целый класс багов, которым tsc и чтение диффа глазами слепы принципиально: они живут во времени, а не в форме. Два маркера — инициализатор, читающий async-данные, и эффект, пишущий в поле по приходу данных. Ловятся они одним приёмом: драйв со временем — воспроизвести порядок событий (печать во время загрузки, перезагрузка, сверка отправленного). И помни: фикс — это изменение; после него запускай заново, ведь лекарство от одного тайминг-бага легко рождает другой.