🏝️ Переводы i18n в каталоге приложений Next.js 13 для серверных/клиентских компонентов 🌊

Исходная статья: https://aralroca.com/blog/i18n-translations-nextjs-13-app-dir

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

Прежде чем мы начнем… Немного контекста

Во-первых, позвольте мне рассказать вам о Next-translate. Это одна из наиболее широко используемых библиотек для загрузки и использования переводов на страницах Next.js (около 70 000 загрузок в неделю). Next.js 9.

По умолчанию переводы хранятся в locales/{lang}/{namespace}.json:

.
├── en
│   ├── common.json
│   └── home.json
└── es
    ├── common.json
    └── home.json

*Однако их также можно загрузить из CDN или интегрировать с онлайн-платформой интернационализации, такой как локализация.

🦄 Одна из целей библиотеки — быть простой в использовании. С небольшой настройкой в файле i18n.js вы уже можете использовать эти переводы на своих страницах и компонентах:

import useTranslation from 'next-translate/useTranslation'

export default function Example() {
  const { t, lang } = useTranslation('common')
  return <h1>{t('example')}</h1>
}

🌍 Еще одна цель библиотеки — иметь все основы i18n: интерполяцию, множественное число, средства форматирования, переводы с HTML-тегами и т. д.

📦 И еще одна цель — быть как можно легче. В версии 1.0 мы заставили его занимать ~1 КБ, но в версии 2.0 было еще больше улучшений, которые мы увидим в этом посте.

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

Теперь, когда я представил библиотеку, давайте посмотрим, по-прежнему ли она проста в использовании, легковесна и содержит ли все основные функции i18n в новой парадигме, которую Next.js 13 представил в конце 2022 года: каталог приложения…

Что такое каталог приложения?

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

Серверные компоненты — это новый тип компонентов React, которые выполняются на сервере и только на сервере. Это означает, что они никогда не отправляются клиенту, что приводит к значительному сокращению объема кода, необходимого для отправки в браузер. Такое сокращение объема кода может повысить производительность приложений React, особенно тех, которые работают с большими объемами данных.

Изначально они задумывались как способ решить "проблему водопада" в приложениях React. Это происходит, когда компоненту React требуются данные с сервера, но эти данные пока недоступны. Это может привести к «водопаду» сетевых запросов, так как каждый компонент ожидает нужных ему данных, прежде чем он сможет их отобразить, что вызывает значительные задержки при отрисовке и влияет на взаимодействие с пользователем. .

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

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

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

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

Головные боли серверных компонентов

Если программист работает и с серверными, и с клиентскими компонентами одновременно, он может столкнуться с некоторыми проблемами с точки зрения интеграции и координации между компонентами. два типа компонентов.

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

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

Загружать и использовать переводы в каталоге приложения Next.js 13

В Next-translate 2.0 мы изо всех сил пытались решить эту проблему, чтобы сделать решение максимально удобным для пользователя. В конце концов, мы достигли этой цели, и в вашем i18n.js нет необходимости в дополнительной настройке. 🎉

Просто имейте в виду, 🧠 что страницы, определенные в конфигурации, теперь используются для страниц в >каталог приложения:

// i18n.js
module.exports = {
  locales: ['en', 'ca', 'es'],
  defaultLocale: 'en',
  pages: {
    '*': ['common'],
    '/': ['home'], // app/page.tsx
    '/checkout': ['checkout'], // app/checkout/page.tsx
  },
}

Это все, что вам нужно сделать! 😜

Наш плагин, который уже присутствовал в Next-translate 1.0, теперь в Next-translate 2.0 обеспечивает загрузку переводов как на серверных, так и на клиентских страницах, а также островков клиентских компонентов на серверной странице. Кроме того, мы уменьшили размер нашей библиотеки с 1,8 КБ до 498 Б (уменьшение + gzip).

До каталога приложений страницы всегда имели 1,8 КБ переводов в пакете, но теперь:

Если у вас есть все переводы в серверных компонентах: 0kb 🥳
Если вам нужны клиентские компоненты острова, которые меняют текст в зависимости от взаимодействия с пользователем: 498B 🎉

Чтобы использовать эти переводы, используйте хук useTranslation или компонент Trans:

🌊 Страница сервера (+0kb): app/page.js:

import useTranslation from 'next-translate/useTranslation'

export default function HomePage() {
  const { t, lang } = useTranslation('home')
  return <h1>{t('title')}</h1>
}

В данном случае мы имеем дело со страницей сервера, поскольку страницы по умолчанию являются серверными компонентами. Под капотом next-translate-plugin динамически загружает переводы напрямую, без использования ловушек useEffect или context. Он также устанавливает язык и пространство имен в HTML, позволяя другим компонентам, таким как островки на стороне клиента, обрабатывать и использовать одни и те же переводы. загружается для страницы.

🏝️ Страница клиента (+498B): app/checkout/page.js

"use client"
import useTranslation from 'next-translate/useTranslation'

export default function CheckoutPage() {
  const { t, lang } = useTranslation('checkout')
  return <h1>{t('title')}</h1>
}

Для клиентских страниц, которые не являются стандартными в Next.js, необходимо указать, что они клиентские, с помощью строки "use client", которая является новой функцией в каталоге app Next.js. 13. По умолчанию, если эта строка отсутствует, страница является серверной. Под капотом next-translate-plugin загружает переводы для этих страниц с помощью хука useEffect. В этом случае нет необходимости добавлять что-либо в HTML, поскольку все компоненты уже будут иметь доступ к переводам. сильный> без необходимости увлажнения.

🏝️ Клиентский компонент (+498B): components/ClientIsland

"use client"
import useTranslation from 'next-translate/useTranslation'

export default function ClientIsland() {
  const { t, lang } = useTranslation('common')
  return <h1>{t('island')}</h1>
}

Та же логика применима и к компонентам: если у них нет строки "use client", они по умолчанию являются серверными, но если они включают ее, они становятся клиентскими островами компонентов, которые можно использовать на странице сервера. .

В этом случае next-translate-plugin проверит, нужна ли гидратация, так как возможно, что переводы уже доступны, если родительская страница или компонент также были клиентом.

🌊 Серверный компонент (+0kb): components/ServerSea

import useTranslation from 'next-translate/useTranslation'

export default function ServerSea() {
  const { t, lang } = useTranslation('common')
  return <h1>{t('sea')}</h1>
}

Для серверных компонентов плагин не выполняет никаких преобразований, так как переводы уже загружены на уровне страницы, а прямой доступ к переводам доступен через хук useTranslation.

🌊🏝️🏝️ Страница сервера с клиентскими островами (+498B): app/page.js

import ServerSea from '@components/ServerSea' // this part 0kb
import ClientIsland from '@components/ClientIsland'
import AnotherClientIsland from '@components/AnotherClientIsland'

export default function HomePage() {
  return (
    <>
      <ServerSea />
      <ClientIsland />
      <AnotherClientIsland />
    </>
}

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

Маршрутизация i18n с каталогом приложений

Next.js 10 представил поддержку маршрутизации i18n, позволяющую отображать страницы путем перехода к /es/page-name, где доступ к странице pages/page-name.js осуществлялся с использованием хука useRouter для получения locale.

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

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

Однако вся доступная в настоящее время поддержка связана с параметром lang. То есть /es/page-name?lang=es отображает страницу app/page-name/page.js, где у нас есть внутренний доступ к параметру lang, и вам не нужно делать что-либо дополнительное, кроме использования хука useTranslation для потребления ваши переводы.

Тем не менее, если вы хотите использовать язык в качестве подпути /es/page-name без параметра, вы можете использовать промежуточное ПО, чтобы добавить параметр lang и выполнить перезапись:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import i18n from './i18n'

// /es/page-name -> rewrites to -> /es/page-name?lang=es
export function middleware(request: NextRequest) {
  const locale = request.nextUrl.locale || i18n.defaultLocale
  request.nextUrl.searchParams.set('lang', locale)
  return NextResponse.rewrite(request.nextUrl)
}

Здесь, в промежуточном программном обеспечении, мы не добавляем локаль в качестве подпути, а устраняем необходимость вручную добавлять параметр lang. По умолчанию вложенный путь все еще существует, но вы не можете использовать useRouter из next/router для доступа к locale внутри компонентов каталога app. Поэтому нам параметр по-прежнему нужен, даже если мы скроем его из поля зрения.

И для навигации:

<Link href={`/?lang=${locale}`} as={`/${locale}`}>{locale}</Link>

Если вам нужны дополнительные функции маршрутизации i18n, такие как автоматическое определение локали, вы можете выполнить следующие шаги из документации Next.js:

https://beta.nextjs.org/docs/guides/internationalization.

Маршруты на разных языках

Демо

В заключение, если вы хотите попробовать пример приложения, использующего Next.js с каталогом app и Next-translate, вы можете взглянуть на этот пример:

Кодовая песочница

Заключение

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

В статье также обсуждается библиотека Next-translate, которая является одной из наиболее широко используемых библиотек для загрузки и использования переводов на страницах Next.js. Он стремится быть простым в использовании, иметь все необходимое для i18n и быть максимально легким. В статье оценивается, остается ли Next-translate простым в использовании, легким и имеет ли он все основные функции i18n в новой парадигме Next.js 13, и объясняет как им пользоваться.