Краткое изложение бета-функции Next.js 13

Next.js 13 приземлился несколько запутанным образом. Добавлено много замечательных вещей; тем не менее, большая часть все еще находится в бета-версии. Тем не менее, бета-функции дают нам важные сигналы о том, как будет формироваться будущее Next.js, поэтому есть веские причины внимательно следить за ними, даже если вы собираетесь подождать, чтобы принять их.

Эта статья является частью серии опытов о бета-функциях. Давайте сегодня познакомимся с новой системой маршрутизации.

Next.js 13 представил совершенно новую папку app с полностью обновленной системой маршрутизации. Он включает в себя множество улучшений, и среди всех лучшим подарком является новый механизм компоновки.

Папка app может сосуществовать со старой папкой pages до тех пор, пока их маршруты не конфликтуют, что позволяет постепенно адаптироваться. Эта история расскажет о самых заметных новых вещах с папкой app.

Новая структура папок

Папка app делает определение маршрутов более явным, требуя, чтобы каждый маршрут был папкой. Папка маршрута обычно содержит следующие файлы маршрута (с суффиксом .js|.ts|.jsx|.tsx):

  • страница —предоставляет пользовательский интерфейс для данного маршрута.
  • макет —предоставляет пользовательский интерфейс макета для этого маршрута и всех дочерних маршрутов.
  • loading — предоставляет загрузочный пользовательский интерфейс, когда загружаются серверные компоненты для маршрута — подробнее об этом в следующем разделе.
  • ошибка —предоставляет пользовательский интерфейс для обработки ошибок внутри и внутри этого маршрута (если только они не обрабатываются другим маршрутом error на дочернем уровне).

Подробнее о серверных компонентах читайте в сюжете ниже.

Макет и вложение

Обновленная структура папок закладывает хорошую основу для введения более условных файлов маршрутов. В результате теперь создавать макеты, делиться ими и размещать их в Next.js стало намного проще, чем когда-либо.

Посмотрим, что изменилось.

В предыдущих версиях

До Next.js 13 официально рекомендуемый подход к созданию вложенного макета заключался в том, чтобы для каждого Page «объявить» свой макет, составить вложенность, а затем применить их на верхнем уровне в pages/_app.

// pages/index.js

export default function Page() {
  return (
    /** Your content */
  )
}

Page.getLayout = function getLayout(page) {
  return (
    <Layout>
      <NestedLayout>{page}</NestedLayout>
    </Layout>
  )
}
// pages/_app.js

export default function MyApp({ Component, pageProps }) {
  // Use the layout defined at the page level, if available
  const getLayout = Component.getLayout || ((page) => page)
  return getLayout(<Component {...pageProps} />)
}

Хотя такой подход приводит к оптимальной производительности (поскольку макеты не перемонтируются при смене маршрута), он громоздкий и неестественный, особенно по сравнению с тем, что предлагает react-router.

С Next.js 13

Новая система маршрутизации делает «макет» первоклассным гражданином. На любом уровне папок под app (т. е. на любом уровне маршрутизации) вы можете использовать layout.tsx для явного определения компонента контейнера. Этот компонент-контейнер будет автоматически обтекать все страницы в этой папке и под ней. При наличии нескольких компонентов layout.tsx на разных уровнях автоматически создается иерархия переноса:

Гораздо проще, чем старый getLayout хак, не так ли?

Также доступна функция «группирования», позволяющая создавать «логические» группы страниц для использования одного и того же макета без введения дополнительного уровня маршрутизации:

Как видите, хотя /about и /blog не используют один и тот же префикс маршрута, они могут использовать один и тот же макет, находясь в одной группе маршрутов. Кому не нравится немного больше гибкости 👻?

Другие примечания

Передача данных из макета в дочерние элементы

Вы не можете этого сделать. Но это не такая серьезная проблема, как может показаться, потому что новый механизм выборки данных в Next.js 13 имеет встроенную дедупликацию и кэширование, поэтому повторная выборка данных в макете и его дочерних компонентах не повредит.

Я расскажу о новой системе получения данных в следующей статье.

Выход из иерархии компоновки

Страница не может избежать предков макета в иерархии маршрутизации. Вам придется тщательно продумывать маршруты или группы маршрутов. Для сравнения, SvelteKit обеспечивает большую гибкость в этом отношении.

Обработка ошибок

Обработка ошибок — небольшая, но удобная функция. Идея довольно проста:

  1. В React есть концепция Границы ошибок для структурированного захвата ошибок.
  2. Папки маршрутов Next.js естественным образом образуют иерархию компонентов.
  3. Почему бы нам не изобрести соглашение для обработки ошибок на любом уровне маршрутизации?

Это то, что делает файл error.tsx. Это не что иное, как синтаксический сахар для упаковки дерева компонентов-потомков в <ErrorBoundary />:

При этом ошибки локализуются в частях пользовательского интерфейса, отображаемых подмаршрутами, не влияя на отображение и интерактивность любых других частей.

Спасибо за прочтение.

Want to Connect?

I'm the creator of ZenStack, a toolkit that supercharges
Prisma ORM with a powerful access control layer and
unleashes its full potential for full-stack development.
Our goal is to let you save time writing boilerplate code
and focus on building what matters - the user experience.