Route groups как границы модулей: доменные оболочки, колокация и налог полной перезагрузки

URL — не ваша модульная система

App-роутер отображает папки в сегменты URL и тем самым тихо сцепляет организацию кода с публичной информационной архитектурой: раз /pricing и /dashboard/billing обязаны жить по этим URL, их код будто бы обязан жить по этим путям. Route groups разрывают сцепку. Папка в круглых скобках — (marketing), (app), (admin) — полностью вырезается из URL: app/(marketing)/pricing/page.tsx по-прежнему отдаёт /pricing. Это делает группы чистой организацией — ровно тем, чем должна быть граница модуля: плоское пространство из 214 папок можно раскроить на домены, закреплённые за squad-ами — по строке CODEOWNERS на группу, — без единого редиректа, и рефакторить инкрементально, потому что пространство URL ничего не замечает. Каждая группа может нести собственные layout.tsx, loading.tsx и error.tsx, так что группа — не просто папка: это область действия оболочки рендеринга, suspense-границы и error-границы одного домена.

Root layout на группу и налог перезагрузки

Самая сильная версия границы — удалить верхний app/layout.tsx и дать каждой группе собственный root layout, каждый из которых сам рендерит теги html и body. Теперь у маркетинга статичная оболочка: шрифты, аналитический скрипт, ноль клиентских провайдеров. У группы приложения — session-провайдер, сайдбар и контекст темы. В том SaaS вынос провайдеров и бандла аналитики из маркетинговой оболочки снизил first-load JS лендингов с 212 до 89 кБ — маркетинговые страницы перестали платить за дашборд, который никогда не рендерят.

Цена структурная, а не случайная: навигация между root layout не может быть клиентским переходом. Роутер патчит часть дерева ниже общего layout, а когда различается сам элемент html, патчить нечего — Next откатывается к полной навигации документа. Вместе с документом умирает всё клиентское состояние: значения контекстов, кеши в памяти, открытый тост, наполовину заполненная форма в провайдере. Переход стоит сетевой раунд-трип плюс полную гидрацию — примерно 0,5–1,5 с на среднем мобильном против ~100 мс у клиентской навигации. Правило проектирования следует напрямую: резать root layout только по швам, которые пользователь редко пересекает посреди сессии. Маркетинг → приложение пересекается один раз, при логине — здесь перезагрузку платить можно. Дашборд → настройки пересекается сорок раз в день — если эта пара попала в разные root layout, граница нарезана неправильно.

Колокация, приватные папки и заслуженное повышение

URL создают только page.tsx и route.ts, поэтому класть не-маршрутные файлы рядом с маршрутами, которые их используют, безопасно по умолчанию. Конвенция, которую стоит закрепить, — подчёркивание: _components/, _lib/ — приватные папки, полностью исключённые из маршрутизации, громкий сигнал, что всё внутри принадлежит этому маршруту и никому больше. У дисциплины две половины. Первая: код живёт рядом с единственным маршрутом, который его использует, — форматтер цен только для чекаута живёт в (checkout)/_lib/, а не в глобальном файле утилит. Вторая: общий код обязан заслужить повышение наружу. Разумная планка: используется двумя и более доменами, имеет именованного владельца, имеет собственные тесты — тогда он переезжает в shared/ (а позже — в workspace-пакет). Выигрыш — инвариант, который ценят зрелые команды: удаление папки маршрута удаляет его UI, мёртвому коду негде прятаться. Провал при пропуске дисциплины — тот самый, из пролога: app/components/ как коммуналка на 200 файлов, где конфликтует каждый PR, ничего нельзя удалить, потому что никто не знает, кто это импортирует, а дубликаты компонентов плодятся, потому что поиск выдаёт 40 кандидатов.

Конвенции не компилируются — направление держит линт

Вот честность о механизме, которой документация сама не предложит: route groups и приватные папки меняют ноль в семантике разрешения модулей. Любой файл может импортировать любой другой через границы групп; TypeScript разрешает импорт, бандлер его отгружает, CI остаётся зелёным. Архитектурная диаграмма, где (billing) не лезет в (admin), — это пожелание, пока инструмент не уронит сборку. Стандартный инструмент — ESLint-правило границ:

// eslint.config.js — зоны import/no-restricted-paths
{
  rules: {
    'import/no-restricted-paths': ['error', {
      zones: [
        // домены не импортируют друг друга — только shared/
        { target: './app/(app)', from: './app/(marketing)' },
        { target: './app/(marketing)', from: './app/(app)' },
        { target: './app/(admin)', from: './app/(app)' },
        // shared/ не импортирует вверх ни в один домен
        { target: './src/shared', from: './app' },
      ],
    }],
  },
}

Группы импортируют из shared/; вбок друг в друга — никогда; shared/ не импортирует ни из одной группы — зависимости направлены в одну сторону, вниз. Когда зоны стоят в CI, боковой импорт — красная сборка, а не комментарий на ревью, который кто-то забудет оставить. Это единственная форма архитектуры, переживающая 40 инженеров, которые поставляют код параллельно.

Параллельные маршруты: композиция для дашбордов

Ещё один инструмент в наборе модульности — параллельные маршруты. Layout может объявить слоты — @revenue, @alerts, @activity — и получить каждый как проп, рендеря их рядом; каждая папка слота несёт собственные loading.tsx и error.tsx, плюс default.tsx на случай, когда слоту нечего матчить. Это даёт дашборду ровно то, что нужно экрану, собранному из независимо принадлежащих панелей: панель squad-а выручки может стримиться с опозданием или падать, не трогая панель алертов, и каждый squad безраздельно владеет папкой своего слота. Честная оговорка о применимости: слоты добавляют реальную сложность файловой системы и тонкое поведение мягкой навигации — прежде чем потянуться к ним, спроси себя: у панелей действительно независимые жизненные циклы данных и ошибок, или просто независимое визуальное расположение?