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

Вы как бы теряете это с RSC. Типа, да, это все еще React, но это две разные парадигмы, и есть много тщательного планирования, которое должно войти в структуру вашего приложения, прежде чем вы начнете кодировать, потому что, по крайней мере, прямо сейчас, есть много «вас». больше так не могу» при использовании каталога NextJS /app для использования преимуществ серверных компонентов.

Давайте посмотрим, что это такое:

В основном это сводится к следующему: код внутри серверных компонентов не может ссылаться на состояние, события DOM или ловушки. Хотя на первый взгляд это имеет смысл (поскольку на сервере его просто нет), я думаю, что введение ограничений там, где их раньше не было, — это шаг назад.

Провайдеры контекста создают еще одно препятствие, поскольку они, по сути, управляют состоянием, а это запрещено в RSC. Довольно распространено иметь провайдера рядом с корнем приложения, чтобы делиться глобальным состоянием и событиями. [также, почему в React нет шины событий?]Поэтому, если вам это нужно, решение состоит в том, чтобы гарантировать, что каждый дочерний элемент поставщика контекста является компонентом на стороне клиента.

Так что же делать, если у вас есть несколько серверных компонентов, которым необходимо совместно использовать извлеченные данные? Рекомендуется просто запрашивать данные несколько раз и позволить NextJS позаботиться об устранении дублирования запросов. Но что, если эти запросы не кэшируются (или не должны кэшироваться)?

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

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

В заключение я отказываюсь меняться, а все остальные не правы.

Николас Ортенцио изобрел, среди прочего, обмакивание кренделей в Nutella.