Традиционно веб-приложения в основном создавались с использованием рендеринга на стороне сервера (т. е. Ruby on Rails или любой другой инфраструктуры MVC), но появление инфраструктуры JavaScript (т. е. React, Vue, Angular) переместило уравнение рендеринга на сторону клиента. Однако метафреймворки, такие как Nuxt и NextJS, вернули истории рендеринга на сервер и даже еще больше усложнили их, предоставляя вам несколько способов рендеринга вашего веб-приложения.
NextJS предлагает 3 основные стратегии рендеринга: генерация статического сайта, рендеринг на стороне сервера и, наконец, что не менее важно, рендеринг на стороне клиента (или SPA). До версии 13.4 эти стратегии рендеринга реализовывались с использованием getStaticProps, getServerSideProps и обычного useEffect. Начиная с версии 13.4, с появлением Серверного компонента React и Маршрутизатора приложений, NextJS отошел от этой модели. Тем не менее, понимание основ этих API по-прежнему очень полезно, поскольку переход определенно займет некоторое время.
Хотя мне хотелось бы подробнее поговорить о том, как компоненты визуализируются с помощью NextJS [¹], я думаю, что важно поговорить об API посредством включения этих стратегий рендеринга. Чтобы легче понять эти API, давайте взглянем на их контекст выполнения. Вы, вероятно, достаточно знакомы с useEffect, поэтому я пока оставлю его в стороне [²].
Когда вы развернули NextJS на сервере, выполняется этап сборки, чтобы подготовить код для запуска в браузере [³]. Это когда вызывается getStaticProps. staticProps будет возвращено и передано компоненту. Он будет вызываться только во время сборки, когда запускается новая сборка. Лично я считаю, что более подходящее имя для этого API — getBuildTimeProp.
В отличие от этого, getServerSideProps НЕ выполняется во время сборки. Скорее, он вызывается, когда ваш сервер NextJS получает запрос на возврат страницы. Короче говоря, serverSideProps будет передано компоненту во время выполнения по запросу. Поэтому я предпочитаю getRequestTimeProp для этого API.
Очень заманчиво отмахнуться от них как от тривиальных и использовать их небрежно. Вы наполовину правы в том, что NextJS очень хорошо предотвращает выстрел себе в ногу. Однако я видел подобную ловушку, работая со многими людьми. Я сам не исключение.
Очень распространенный шаблон — совмещение вашего функционального компонента и getServerSideProps/getStaticProps в одном файле. Хотя это может облегчить понимание вашего кода, на самом деле здесь вы смешиваете контекст выполнения. Вы можете потратить часы на отладку, если не знаете, когда и где запускается ваш код. Небольшой совет: убедитесь, что вы передаете правильное свойство своему компоненту.
Я действительно считаю, что серверный компонент — это большой шаг вперед в упрощении получения данных на сервере, но нам все равно придется бороться с этим API в течение следующих нескольких лет. Изучение того, как эффективно их использовать, поможет вам освоить NextJS и работать более эффективно. Если вы изо всех сил пытаетесь разобраться в Next, я очень надеюсь, что мой пост вам чем-то помог.
[1] На самом деле NextJS независимо от этого также отображает ваш компонент на сервере. Попробуйте распечатать файл console.log, и вы увидите.
[2] При использовании useEffect можно столкнуться со многими ловушками, но они не являются эксклюзивными для NextJS.
[3] Это довольно чрезмерное упрощение. процесса. Вы могли бы потратить часы и часы только на это.
