Кратко о том, зачем нужны layout

Layout — это компонент-обёртка, который задаёт общий каркас страниц: шапку, подвал, глобальные стили и скрипты. Он помогает избежать дублирования, сделать дизайн единообразным и упростить поддержку.

Ключевые преимущества:

• Повторное использование общих частей (Header, Footer, навигация).
• Централизованное подключение глобальных метаданных и стилей.
• Упрощённые изменения интерфейса (изменили в layout — обновилось везде).

Создание кастомного layout в папке components (pages router, Next.js ≤12)

В папке components создайте файл Layout.jsx и поместите туда рабочий компонент-обёртку. Пример корректного варианта:

import Head from 'next/head'
import Header from './Header.jsx'
import Footer from './Footer.jsx'

const Layout = ({ children }) => (
  

    
      
      
    

    


    
{children}

    
)

export default Layout

Пояснения:

• Layout принимает { children } как пропс — это содержимое страницы.
• Используйте semantic-элементы (main, header, footer) для доступности.
• Head из next/head применяется в pages-роутинге.

Использование Layout на странице (pages)

Импортируйте и обёрните содержимое страницы:

import Layout from '../components/Layout'

const Page = () => (
  
    
Home
    
Контент главной страницы
  
)

export default Page

Если хотите применить layout ко всем страницам сразу — подключите его в файле pages/_app.js:

import Layout from "../components/Layout";

function MyApp({ Component, pageProps }) {
  return (
    
      
    
  );
}

export default MyApp;

Root layout в app router (Next.js 13+)

В новой app-структуре нужно создать root layout в корне папки app: файл layout.jsx обязателен. Пример минимального корня:

export default function RootLayout({ children }) {
  return (
    
      {children}
    
  )
}

Особенности root layout:

• Должен находиться в папке app в самом её корне.
• Заменяет _app.js и _document.js из pages-роутинга.
• Нужны теги html и body — их нужно явно вернуть.
• По умолчанию это серверный компонент (Server Component).

Вложенные layout для сегментов маршрутов

В app-роутинге вы можете организовать вложенные layout по структуре папок. Правила:

• Папка app/articles соответствует пути /articles.
• Добавьте layout.jsx в app/articles — он будет применяться ко всем страницам внутри articles и дочерних папок.
• Если в app/articles/trending есть свой layout.jsx, он будет оборачивать layout из articles (вложенность).

Так можно формировать общие элементы верхнего уровня и частные для разделов сайта.

Практические советы и лучшие практики

• Разделяйте визуальную структуру и логику — layout отвечает за каркас, не за бизнес-логику страницы.
• Держите state локальным там, где он нужен; для глобального состояния используйте Context или хранилище.
• Помните о доступности: используйте semantic-разметку и aria-атрибуты.
• Для динамических данных (например, меню с API) решите, где выполнять fetch: в server component (корректно для SEO) или в client component.
• Добавляйте критичные метаданные (charset, viewport) в root layout или в Head на уровне страниц.

Частые ошибки и когда layout не подходит

• Если каждая страница существенно отличается по структуре, layout может увеличить сложность и привести к условным рендерам.
• Не превращайте layout в «монстра» с множеством условий — лучше создать несколько небольших layout для разных групп страниц.
• Не используйте client-only библиотеки напрямую в server layout — добавьте “use client” в дочерний компонент.

Миграция с pages → app: чек‑лист

1. Создать app/layout.jsx (root layout).
2. Перенести глобальные Head, стили и скрипты в root layout.
3. Преобразовать pages/_app.js логику в соответствующие layout или providers в app.
4. Разбить большие layout на несколько вложенных, если нужно разное оформление для секций.
5. Переписать client-side хук‑логику в компоненты с директивой “use client”.
6. Тестировать маршруты и SSR/SSG поведение.

Роль‑ориентированные чек‑листы

Разработчик:

• Проверить структуру папок app и наличие layout.jsx
• Убедиться, что html и body возвращаются в корневом layout
• Перенести глобальные стили и Head

Дизайнер:

• Предоставить вариант общего header/footer и мобильную версию
• Согласовать точки перелома и поведение навигации

PM/Техлид:

• Решить, какие страницы будут использовать один layout
• Оценить влияние на время загрузки и SEO

Мини‑методология проектирования layout (3 шага)

1. Инвентаризация: перечислите общие элементы всех страниц (header, footer, боковая панель).
2. Группировка: объедините страницы по шаблонам (например, статьи, профиль, магазин).
3. Реализация: создайте root layout и вложенные layout для каждой группы, минимизируйте условную логику.

Пример: сочетание серверного layout и клиентских компонентов

Если root layout — серверный компонент, а внутри нужен интерактивный компонент (например, корзина), поместите его в отдельный файл с директивой “use client”:

// components/CartClient.jsx
"use client"
import { useState } from 'react'

export default function CartClient() {
  const [open, setOpen] = useState(false)
  return (
    

       setOpen(!open)}>Корзина
      {open && 
Элементы корзины...
}
    
  )
}

Этот компонент можно безопасно вставить в layout или страницу.

Критерии приёмки

• Header и Footer отображаются на всех страницах, где это нужно.
• Корневой layout содержит html и body.
• Вложенные layout корректно оборачивают дочерние страницы.
• Клиентские компоненты работают и не ломают серверный рендеринг.

Короткий шаблон README для команды

• Где: app/layout.jsx — корень, components/Layout.jsx — общий для pages.
• Правило: минимизировать бизнес-логику в layout.
• Тесты: ручная проверка на нескольких устройствах + unit для client components.

Словарь (одна строка)

layout — компонент-обёртка для повторяющейся структуры страниц.

Краткое резюме

Layout в Next.js упрощают поддержание единого дизайна и ускоряют изменения в проекте. В pages-роутинге используйте components/Layout + _app.js, в app-роутинге — root layout и вложенные layout для сегментов. При миграции соблюдайте чек-лист и делайте клиентские компоненты отдельными.

Важно: выбирайте структуру, исходя из архитектуры проекта и требований к SEO/SSR.