docs(guides): update next.js tech guide to the relevant status

[GeorgKrom]

Перенёс приоритет с pages на app router, добавил небольшие примеры с импортами и тезисно дописал несколько рекомендаций

[Copilot]

Pull Request Overview

A concise update of the Next.js integration guide to prioritize the App Router, add import examples, and flesh out recommendations.

• Standardize all references from “NextJS” to “Next.js” and reorganize conflict sections.
• Introduce code snippets for re-exporting pages, middleware, instrumentation, and route handlers.
• Enhance guidance with additional recommendations and updated links to Next.js documentation.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
i18n/ru/docusaurus-plugin-content-docs/current/guides/tech/with-nextjs.mdx	Refined headings and routing sections, added App Router examples, middleware/instrumentation/route-handler guidance, and extra recommendations
i18n/en/docusaurus-plugin-content-docs/current/guides/tech/with-nextjs.mdx	Mirrored updates in English: standardized naming, new code examples, and extended best practices

Comments suppressed due to low confidence (2)

i18n/ru/docusaurus-plugin-content-docs/current/guides/tech/with-nextjs.mdx:66

• Тип IProps не определён в примере; скорее должен использоваться AppProps из Next.js или необходимо добавить определение интерфейса IProps.

const App = ({ Component, pageProps }: IProps) => {

i18n/en/docusaurus-plugin-content-docs/current/guides/tech/with-nextjs.mdx:65

• The example uses an undefined IProps type; it should use AppProps from Next.js or include a definition for IProps.

const App = ({ Component, pageProps }: IProps) => {

[illright]

Спасибо, стало намного лучше! Оставил несколько предложений по улучшениям

[illright]

issue: this part isn't clear to me. You mention that it's recommended to use the routes segment, but the code block below doesn't demonstrate it.

suggestion: let's also add a code block where getExample is defined so that it's clear how and where to define route handlers

But also, should this really be in the FSD structure? I feel like mixing in unrelated backend code into the frontend code folder might make it hard to find. Let's discuss and refine this point a bit, perhaps also get people from the chat to give their opinion

[GeorgKrom]

But also, should this really be in the FSD structure? I feel like mixing in unrelated backend code into the frontend code folder might make it hard to find. Let's discuss and refine this point a bit, perhaps also get people from the chat to give their opinion

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

[illright]

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

• уберем из рекомендаций предложение хранить их в pages — они не имеют отношения к страницам, пусть уж будут в app только
• сделаем два код-блока в этой секции, первый в src/app/api-routes (мне больше нравится api-routes, потому что тогда не путаем с роутами, по которым находятся страницы), и в нем прямо полноценное описание функции-хендлера getExampleData. Внутри этой функции можем даже заюзать db из shared/db, чтоб продемонстрировать реюз коннекшна между роут-хендлерами и серверными компонентами
• второй код-блок в app/api/example, и он реэкспортирует getExampleData as GET

[GeorgKrom]

@illright, привет, хотел напомнить о себе и обсудить сегмент роутов, каких-то комментариев из ребят в чате особо выудить не получилось

[illright]

Привет, спасибо, да, завтра посмотрю основательно апдейты

[illright]

Так, наконец-то собрался с мыслями. Спасибо за терпение :) Отписал свои мысли по поводу вопросов, которые поднимал на прошлом раунде комментариев

[illright]

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

• уберем из рекомендаций предложение хранить их в pages — они не имеют отношения к страницам, пусть уж будут в app только
• сделаем два код-блока в этой секции, первый в src/app/api-routes (мне больше нравится api-routes, потому что тогда не путаем с роутами, по которым находятся страницы), и в нем прямо полноценное описание функции-хендлера getExampleData. Внутри этой функции можем даже заюзать db из shared/db, чтоб продемонстрировать реюз коннекшна между роут-хендлерами и серверными компонентами
• второй код-блок в app/api/example, и он реэкспортирует getExampleData as GET

[illright]

issue: это какая-то не очень понятная секция, без текста, только кодовый блок. Помимо этого, мне кажется, Steiger будет ругаться на индекс-файл в app, но я не уверен

suggestion: хочется найти какое-то более стабильное место кастомному компоненту App. При этом, не хочется выдумывать для него другие имена, которые не будут знакомы Next-разработчикам. Может, забить и просто предложить людям создать в слое app сегмент _app? Повторение, конечно, но зато сразу понятно всем, кто знают Pages Router. Альтернативно можно предложить custom-app

И давай заголовок этой секции сделаем вот такой:

Suggested change

	### Functionality re-export from the public API `src/app/index.ts` to `pages/_app.tsx`
	### Custom `_app` component

И чуть текста добавим, типа "You can place your Custom App component in src/app/_app or src/app/custom-app, и затем ниже привести опять же два код-блока — один с содержимым кастомного аппа, другой с реэкспортом в нужное место