Рендеринг на стороне сервера

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

❓В чем принципиальная разница?

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

‼️ Какие подходы есть?

1. Просто оставить ключевые страницы сайта статическими (никаких вам SPA).

2. Делать SPA, но во время сборки генерировать статические страницы для него (библиотека react-snaphot, потом взглянем на нее). Очевидно, эти страницы будут использоваться как точки входа с хорошим SEO, а затем вступит в дело механизм SPA. Но тут есть вопросы с разными динамическими данными (апи, данные, передаваемые в урле)

3. Использовать технологии для полноценного серверного рендеринга (часть кода будет выполняться на сервере, например, Next.js).
Тут тоже есть два подхода:
- SSG (статическая генерация сайта) - что-то очень похожее на пункт 2, но покруче. Статические страницы рендерятся при сборке проекта. Доступны даже динамические урлы.
- SSR (рендеринг на стороне сервера) - что-то очень похожее на старый-добрый рендеринг на сервере, когда рендер происходит при каждом запросе.

Основное внимание мы уделим, конечно, Next.js. Также мельком глянем на react-snapshot.

#серверныйрендеринг

​Next.js. Начало

Next.js - это инструмент, который должен нам помочь превратить обычное SPA на React в изоморфное приложение. То есть такое приложение, которое сначала выполнится на сервере и сгенерирует нам статические HTML-странички. А затем эти странички в браузере пользователя пройдут через процедуру гидратации и превратятся в нормальное SPA с роутингом и прочими плюшками.

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

При этом в отличие от "классического" серверного рендеринга (как на PHP-сайтах), наше приложение, по идее, не будет иметь дела с данными напрямую, даже на сервере. Оно должно обращаться к некому API-серверу, чтобы получать то, что нужно в виде JSON.

В этот раз начнем не с документации, а с видео-курса, возможно, так будет попроще.

Курс (от Владилена Минина) здесь: https://www.youtube.com/watch?v=_EOrSmjdOZQ
продолжительность 2,5 часа

Разворачиваем проект

Для быстрого разворачивания проекта на Next.js используем утилиту create-next-app (как create-react-app). Получаем шаблонный Next-проект.

Что тут есть интересного:

- папка pages, в которой будут лежать все наши странички. Тут уже лежат файлы index.tsx, api/hello.ts и пара файлов, у которых имена начинаются с нижнего подчеркивания (вероятно, они не превратятся в отдельные страницы)

- папка public - очевидно, публичные ресурсы, которые будут скопированы в собранный проект

- папка styles с файлами global.css и Home.module.css. Видимо, это система организации стилей по умолчанию. Потом посмотрим, как прикрутить что-нибудь другое

- в package.json есть скрипты dev, start и build.

Если запустить npm run dev, развернется локальный сервер с демо-страницей.

Никакого App.tsx или чего-то подобного нет, точка входа в проект, очевидно, pages/index.tsx.

#серверныйрендеринг #nextjs

​Next.js. Роутинг на файлах

Роутинг в Next.js основан на файлах. Каждый файл в папке pages это отдельная страничка нашего сайта, к которой можно получить доступ по ее имени.

Например, файл pages/index.tsx - это корневая страница нашего проекта, в данном случае localhost:3000/.
Файл pages/posts.tsx - это страница localhost:3000/posts/.

В каждом таком файле находится самый обычный React-компонент (экспортируется по умолчанию).

Страницы можно вкладывать в папки, например, pages/about/contacts.tsx. Этот компонент будет доступен по адресу /about/contacts/.

#серверныйрендеринг #nextjs

Чтобы убедиться, что это не обычное SPA-приложение, а именно заранее отрендеренный на сервере документ, можно открыть код страницы или посмотреть первый запрос в панели Network - там будет HTML-документ с уже вставленным текстом. Получается, что компонент отрендерился на сервере и пришел в браузер уже в готовом виде.

Кроме того тут можно увидеть скрипт с id __NEXT_DATA_, который содержит какой-то JSON. Предположительно, это данные для гидратации приложения на клиенте.

#серверныйрендеринг #nextjs

​Next.js. Динамические роуты

Next позволяет работать не только с простыми роутами типа / или /about/contacts, но и с динамическими фрагментами. Например, это могут быть страницы статей post/1, post/2 и так далее.

Динамическая часть такого роута заключается в квадратные скобки: pages/post/[id].tsx.

Чтобы получить значение динамических параметров, нужно использовать хук роутера - useRouter из пакета next/router.

const router = useRouter();
console.log(router);

Параметры находятся в поле router.query.

Теперь можно перейти на страницу http://localhost:3000/post/1.

При этом в консоли сервера тоже появится объект роутера, ведь сначала компонент выполняется на сервере.

#серверныйрендеринг #nextjs

​Next.js. Клиентский роутинг

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

Для этого Next предоставляет компонент Link, который работает так же, как и Link из React, только при выполнении на сервере он превращается в обычную HTML-ссылку.

Адрес ссылки указывается в пропе href.

Для программной навигации нужно использовать метод Router.push

Демо: https://codesandbox.io/p/sandbox/stupefied-sutherland-r0xd40?selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A4%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A4%7D%5D&file=%2Fpages%2Findex.tsx

#серверныйрендеринг #nextjs #примерыкода

Next.js. Мета-данные страницы

Весь этот серверный рендеринг затевался для того, чтобы сделать наши страницы лучше в плане SEO. Давайте же этим сео и займемся.

Next предоставляет компонент Head, в который можно поместить любые теги, которые должны быть в секции head страницы (title, meta-теги). Размещать этот компонент можно в любом месте страницы.

#серверныйрендеринг #nextjs

Компоненты/лейауты, которые переиспользуются на разных страницах, нужно вынести за пределы папки pages, так как в pages должны лежать именно страницы.

#nextjs #серверныйрендеринг #примерыкода

​Next.js. Файл pages/_document

Есть возможность изменить базовую HTML-структуру страницы, для этого нужно создать свой файл pages/_document.tsx. Компонент в этом файле может по своему усмотрению разместить компоненты Html, Head, Main и NextScript (импортируются из next/document).

- Html - корневой узел документа.
- Head - это head, но не тот же самый, который мы уже встречали в next/head. Этот head (next/document) предназначен для размещения кода, общего для всех страниц. Тот head (next/head) - для размещения отличающегося кода, например, title, на отдельных страницах.
- Внутрь Main будет вставляться активная страница. Все, что находится вне Main, не будет инициализировано, поэтому сюда не нужно добавлять какую-то логику.
- NextScript - это скрипты, которые нужны для работы Next.js.

Компонентам можно добавлять атрибуты (например, lang).

Страница в документации (англ.): https://nextjs.org/docs/advanced-features/custom-document

#nextjs #серверныйрендеринг

​Next.js. Файл pages/_app

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

Кроме того, именно в этом месте мы можем добавить глобальные стили для приложения.

UPD: также, здесь, кажется, хорошее место для размещения провайдеров глобальных контекстов.

Для этого создаем файл pages/_app.tsx.

В базовом варианте он выглядит очень просто:

- принимает пропсы Component (компонент активной страницы) и pageProps
- и просто рендерит этот компонент с этими пропсами.

Страница в документации (англ.): https://nextjs.org/docs/advanced-features/custom-app

#nextjs #серверныйрендеринг

Next.js. Стили

Что по стилям?

1. Если нам нужны какие-то глобальные стили, то можно импортировать .css-файлы в наш кастомный компонент App (файл pages/_app.tsx). Но такой трюк пройдет только здесь. При попытке импортировать .css-файл с глобальными стилями на какую-нибудь страницу или в компонент, вылетит ошибка:

Global CSS cannot be imported from files other than your Custom App. Due to the Global nature of stylesheets, and to avoid conflicts, Please move all first-party global CSS imports to pages/_app.js. Or convert the import to Component-Level CSS (CSS Modules).

2. Однако внутри компонентов/страниц мы можем импортировать стили сторонних библиотек (из node_modules).

3. Если необходимо импортировать свои стили в компонент, нам предлагают пользоваться CSS-модулями (разбирали их здесь).

4. Можно использовать препроцессоры, например, SCSS, но понадобится установить пакет sass. Поддерживается даже прямой импорт и использование SASS-переменных в файлах компонентов.

5. Документация уверяет, что поддерживаются любые решения CSS-in-JS. Действительно, со Styled Components проблем не возникло. Глобальные стили (createGlobalStyles) следует размещать в файле _app.tsx.

6. Также нам предлагают использовать styled-jsx, который поддерживается из коробки. При этом можно писать стили прямо в JSX-разметке, внутри тега style как обычный CSS (документация тут).

#nextjs #серверныйрендеринг #стили

Нашелся старый пост с субъективным сравнением разных способов стилизации React-приложений: https://yangx.top/react_junior/229

Надо признать, что с тех пор мои предпочтения немного изменились и в большинстве своих проектов я использую Styled Components. Синтаксис стал привычнее, и в целом это решение весьма удобное. НО! - только если стилей мало. Для больших простыней по-прежнему предпочитаю модули + препроцессоры.

#стили

Next.js. Страница 404

По умолчанию Next предлагает свою страницу 404 для несуществующих роутов, но мы можем ее заменить. Для этого нужно просто создать файл pages/404.tsx и вернуть из него нужный компонент.

Демо-проект: https://codesandbox.io/p/sandbox/stupefied-sutherland-r0xd40?selection=%5B%7B%22endColumn%22%3A2%2C%22endLineNumber%22%3A3%2C%22startColumn%22%3A2%2C%22startLineNumber%22%3A3%7D%5D&file=%2Fpages%2F404.tsx

#nextjs #серверныйрендеринг

Next.js. Получение данных на сервере

Переходим к самому интересному. Как сделать так, чтобы на клиент приходила страница уже с данными. Например, список постов? Нужно запросить данные еще на сервере и уже с ними отрендерить компонент, чтобы клиент получил готовый HTML.

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

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

Метод должен вернуть объект, который будет передан в компонент как пропсы.

Получим например, список постов для страницы posts.tsx:

export default function Posts({ posts }) {
    //..
}

Posts.getInitialProps = async () => {
  const response = await fetch('https://jsonplaceholder.typicode.com/posts');
  const posts = await response.json();

  return {
    posts
  }
}

Работает это вполне логично:

1. Сервер получает запрос к странице Posts.
2. Видит, что у компонента этой страницы есть метод getInitialProps и выполняет его.
3. То, что получилось на выходе, передается в сам компонент в виде пропсов.
4. Компонент рендерится в HTML-код.
5. Клиент получает готовую страницу (уже с данными).

Звучит прям ну очень знакомо, да? Классический серверный рендеринг.

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

#nextjs #серверныйрендеринг

Next.js. getInitialProps

Метод getInitialProps вызывает каждый раз при переходе на страницу. И при первом запросе, когда сервер рендерит нам страницу, и при каждом переходе на клиенте, в режиме SPA.

То есть, мы вводим в адресную строку урл localhost/posts - сервер выполняет запрос для получения нужных пропсов - страница загружается уже с данными.

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

Можно использовать такой подход:

- если метод вызывается на сервере (для первичного рендеринга приложения), то оставить все как есть
- если метод вызывается на клиенте (при переходе с другой страницы SPA), не вызывать getInitialProps. По сути мы быстро отрендерим пустой компонент (без пропсов), а уже потом (в хуке useEffect) загрузим нужные данные, показывая в это время понятный лоадер.

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

getInitialProps при вызове получает один аргумент - контекст вызова. В нем куча данных, в том числе объекты req и res - HTTP-запрос и HTTP-ответ соответственно. Они приходят только если вызов произошел на сервере, то есть по их наличию можно ориентироваться.

export default function Posts({ posts }) {
    const [postsList, setPostsList] = useState(posts);
    useEffect(function() {
        if (!posts) {
            // загрузить посты на клиенте
        }
    })

    if (!posts) {
        // вернуть лоадер
    }

    // вернуть страницу с постами
}

Posts.getInitialProps = async ({ req }) => {
  if (!req) {
    return { posts: null }
  }
  
  const response = await fetch('https://jsonplaceholder.typicode.com/posts');
  const posts = await response.json();

  return {
    posts
  }
}

#nextjs #серверныйрендеринг

Next.js. getInitialProps - параметры

Тот же подход можно использовать для предварительной загрузки поста на сервере - страница post/[id]. Но тут нам нужно знать значение динамического параметра.

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

export default SinglePost({ post }) => {
  // ...
};

SinglePost.getInitialProps = async ({ query }) => {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts/${query.id}`
  );
  const post = await response.json();
  return {
    post,
  };
};

#nextjs #серверныйрендеринг

​Next.js + TypeScript

Для описания страниц в Next-приложении нам потребуется тип NextPage (импортируется из пакета next). Это дженерик, который принимает тип пропсов компонента.

#nextjs #серверныйрендеринг #typescript

​Next.js. getServerSideProps

Вероятно, вместо getInitialProps лучше использовать getServerSideProps.

Идея такая же, но getServerSideProps работает ТОЛЬКО на сервере (не запускается при переходе между страницами на клиенте в режиме SPA. То есть данные запрашиваются один раз и переиспользуются при загрузке страницы любым способом.

Разница:

- getInitialProps это статический метод компонента, а getServerSideProps просто функция, которую нужно импортировать из файла страницы.
- getServerSideProps должна вернуть объект с полем props.
- так как getServerSideProps работает только на сервере, нам не требуется проверять наличие req.

#nextjs #серверныйрендеринг

Все виды Server-side рендеринга в NextJS: SSR, CSR, SSG, ISR

Видео (рус.): https://www.youtube.com/watch?v=xg-lajRmCco

Видео на 15 минут с обзором различных способов рендеринга в современном фронтенде. Примеры в основном на Next.js (React).

CSR - Client Side Rendering

Самая привычная нам форма работы, при которой все запросы исходят с клиента и DOM полностью формируется на клиенте.
Из минусов:
- долгая первая загрузка бандла (потом его можно закешировать), при которой пользователь видит только пустую страницу
- плохая SEO, так как поисковик тоже видит пустую страницу

SSR - Server Side Rendering

В этом подходе сервер самостоятельно рендерит страницу (при необходимости получает для нее данные) и отдает на клиент уже готовый HTML, который затем проходит гидратацию и становится нормальным SPA. Это SEO friendly, тратит меньше ресурсов устройства, но требуется время для подготовки страницы на сервере.

SSG - Static Site Generation

Другой способ - отрендерить все страницы сразу же, во время сборки проекта, не дожидаясь запросов пользователя. Готовые HTML складываются на сервере и при запросе сразу отдаются без затрат времени на подготовку. Не подходит для контента который должен быть актуальным. Также сомнительный способ, если на вашем сайте тысячи страниц (например, большой блог).

ISR - Incremental Static Regeneration

Та же SSG, но с возможностью обновить сгенерированные страницы по таймеру.

#serversiderendering #nextjs #ssr #ssg #isr