Архитектура фронтенда
Data fetching: тест с краткими ответами
Припоминание лучше перечитывания. На каждый промпт скажи или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет ментальную модель юнита.
Реконструируй стержень юнита — почему место fetch решает LCP, как формируются и растворяются waterfall’ы, что покупают RSC streaming и SWR-кэш, и как работает многослойная инвалидация — не заглядывая обратно в уроки.
- 01Почему место data fetching решает LCP сильнее, чем скорость сети?
- 02Почему useEffect-fetch'и на уровне компонентов образуют waterfall даже при независимых данных, и какие три паттерна его растворяют?
- 03В чём правило границы 'use client' и чего стоит пометка всего 'use client'?
- 04Объясни stale-while-revalidate и single-flight-дедупликацию в TanStack Query / SWR.
- 05Каков канонический паттерн optimistic update и в чём классический баг?
- 06Назови слои кэша в приложении Next.js 15 и почему мутация должна инвалидировать больше одного.
Если ты смог реконструировать каждый ответ по памяти, ты держишь стержень юнита: место fetch задаёт число round-trip’ов на critical path и потому LCP; каскад рендера сериализует независимые fetch’и в waterfall’ы, которые растворяют Promise.all, useQueries или соседние RSC-компоненты; Server Components отгружают ноль JS только когда остаются на сервере, а Suspense streaming покупает низкий TTFB; клиентский кэш делает повторные визиты мгновенными через stale-while-revalidate и single-flight, а optimistic update требует полного снимка; и каждая мутация должна инвалидировать каждый затронутый слой кэша — одной серверной ревалидации мало.