Форма состояния: тест с выбором ответа
Тест с множественным выбором по всему юниту про форму state — derived state, server cache vs клиентский state, colocation, URL-состояние и трейдоффы normalized.
Шесть вопросов, проходящих через весь юнит. Каждый отражает решение, которое ты принимаешь до того, как тянешься к любой библиотеке state — не определение, чтобы пересказать, а форму, которую надо выбрать под реальные ограничения.
Убедись, что связываешь стержень юнита: выводи выводимое, отделяй server cache от клиентского state, колоцируй у нижнего читателя, шарящееся view-состояние выноси в URL, а реляционные данные нормализуй только когда их мутируешь.
Список товаров получают из API, и его читают три соседних компонента на одном экране. Какая форма правильная?
Бейдж-счётчик показывает '127', а в списке 9 строк; count лежит в useState рядом с массивом results. В чём корневая причина и фикс уровня сеньора?
Булево open/closed для тултипа лежит в корневом store приложения «чтобы было доступно везде». Почему это неверная форма?
Фильтры и id открытой детали лежат только в useState. Скопированная ссылка открывает у коллеги пустой дефолтный вид, а рефреш тоже всё сбрасывает. Какую форму упустили?
Клиентский редактор держит threads, posts и users вложенно, как вернул API, и пользователей переименовывают постоянно. После переименования часть вью показывает старое имя. Почему и какая форма это чинит?
Команда хранит selectedUser как целый объект user в state. После правки в другом месте, обновившей этого user, выбор всё ещё показывает старые поля. В чём урок про форму?
Стержень юнита — одно дерево решений: если значение выводимо (count, выбранный объект), не храни его — вычисляй в рендере или джойни по id. Если это state, спроси, чьё оно — полученные с сервера данные это cache (React Query/SWR), шарящееся клиентское view-состояние идёт в URL, а остальное колоцируется у нижнего общего предка читателей, чтобы радиус ререндеров был мал. Реляционные клиентские данные нормализуй в byId-словарь только когда их мутируешь. Теперь, когда встретишь любой из этих дистракторов в реальном PR — выводимое значение рядом со своим источником, полученные данные в Redux-слайсе, флаг с одним читателем в корне, снимок объекта вместо join по id — ты знаешь имя ошибки формы, сбой, который она вызовет, и структурный фикс, который её убирает.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.