В декабре мы написали первые впечатления от App Router. С тех пор перевели ещё четыре проекта, набили шишки и выработали внутренние правила. Текст для тех, кто думает идти на App Router в 2023-м.
Что окончательно зашло
Server Components как дефолт
Мы перевернули привычку: теперь по умолчанию пишем серверный компонент, а 'use client' добавляем только когда нужно. Раньше было наоборот, и интуиция подсказывала «лучше клиент». Изменение мышления заняло у команды месяца полтора.
Колокация данных
Fetch внутри компонента, который этими данными пользуется. Без props drilling, без отдельных hooks-слоёв, без Redux. На одном проекте мы удалили 4400 строк кода, которые занимались прокидыванием данных от страницы к листовому компоненту.
Что бесит до сих пор
Кэш
Четыре уровня кэша в Next 13 - это много. Request memoization, data cache, full route cache, router cache. Мы написали внутренний one-pager «куда смотреть, если не обновляется» и заставили всех его выучить наизусть.
Server Actions в alpha
Заявлены, обсуждаются, в проде использовать страшно. На пилоте нашли два кейса с double-submit и один с гонкой при revalidate. Вернулись на классические API-routes. Подождём beta.
Правила, которые мы ввели для всех новых проектов
- Server Component по умолчанию. Client - только при наличии state, эффекта или браузерного API.
- Никаких 'use client' выше, чем нужно. Сужайте границу до листовых компонентов.
- Fetch - рядом с компонентом-потребителем. Если данные нужны нескольким - поднимайте до общего родителя, не выше.
- Никакого fetch в клиенте при первом рендере. Только в ответ на действие пользователя.
- revalidatePath после мутаций - обязательно, даже если кажется, что и так перерисуется.
Метрики, которые получили
- Средний размер JS-бандла на новых проектах - 78 КБ против 142 КБ на Pages Router.
- TTI на 3G - 2.4 с против 4.1 с.
- Время сборки прод-бандла - стало хуже, +35% (тут App Router пока проигрывает).
- Время онбординга нового разработчика в проект - выросло. Учить нужно больше концепций.