Создание React-приложения с нуля

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

Шаг 1: Установите инструмент сборки

Первый шаг — установить инструмент сборки, такой какvite,parcelилиrsbuild. Эти инструменты сборки предоставляют функции для упаковки и запуска исходного кода, обеспечивают сервер разработки для локальной разработки и команду сборки для развёртывания вашего приложения на продакшн-сервере.

Vite

Vite— это инструмент сборки, который стремится обеспечить более быстрый и лёгкий опыт разработки для современных веб-проектов.

npm create vite@latest my-app -- --template react-ts

Vite имеет продуманную архитектуру и поставляется с разумными настройками по умолчанию. У Vite богатая экосистема плагинов для поддержки быстрого обновления, JSX, Babel/SWC и других распространённых функций. См.плагин Reactилиплагин React SWCот Vite, а такжепример проекта React SSR, чтобы начать.

Vite уже используется в качестве инструмента сборки в одном из нашихрекомендуемых фреймворков:React Router.

Parcel

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

npm install --save-dev parcel

Parcel поддерживает быстрое обновление, JSX, TypeScript, Flow и стилизацию из коробки. См.рецепт Parcel для React, чтобы начать.

Rsbuild

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

npx create-rsbuild --template react

Rsbuild включает встроенную поддержку функций React, таких как быстрое обновление, JSX, TypeScript и стилизация. См.руководство Rsbuild по React, чтобы начать.

Шаг 2: Создайте общие паттерны приложения

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

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

Маршрутизация

Маршрутизация определяет, какой контент или страницы отображать, когда пользователь посещает определённый URL. Вам нужно настроить маршрутизатор для сопоставления URL с различными частями вашего приложения. Также вам потребуется обрабатывать вложенные маршруты, параметры маршрутов и параметры запроса. Маршрутизаторы можно настраивать в коде или определять на основе структуры папок и файлов компонентов.

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

We suggest using:

• React Router
• Tanstack Router

Получение данных

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

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

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

Если вы получаете данные из большинства бэкендов или REST-подобных API, мы предлагаем использовать:

• TanStack Query
• SWR
• RTK Query

Если вы получаете данные из GraphQL API, мы предлагаем использовать:

• Apollo
• Relay

Разделение кода

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

Аналогично, если вы полагаетесь на то, что приложения, использующие ваш фреймворк, будут разделять код, вы можете столкнуться с ситуациями, когда загрузка становится медленнее, чем если бы разделения кода вообще не происходило. Например,ленивая загрузкаграфика откладывает отправку кода, необходимого для его отрисовки, отделяя код графика от остальной части приложения.Parcel поддерживает разделение кода с помощью React.lazy. Однако, если график загружает свои данныепослепервоначальной отрисовки, вы теперь ждете дважды. Это каскад: вместо того чтобы одновременно получать данные для графика и отправлять код для его отрисовки, вы должны ждать завершения каждого шага один за другим.

Разделение кода по маршрутам, при интеграции со сборкой и получением данных, может сократить время первоначальной загрузки вашего приложения и время, необходимое для отрисовки самого крупного видимого контента приложения (Largest Contentful Paint).

Инструкции по разделению кода смотрите в документации вашего инструмента сборки:

• Оптимизации сборки Vite
• Разделение кода в Parcel
• Разделение кода в Rsbuild

Улучшение производительности приложения

Поскольку выбранный вами инструмент сборки поддерживает только одностраничные приложения (SPA), вам потребуется реализовать другиешаблоны рендеринга, такие как серверный рендеринг (SSR), генерация статических сайтов (SSG) и/или React Server Components (RSC). Даже если вам изначально не нужны эти функции, в будущем некоторые маршруты могут получить выгоду от SSR, SSG или RSC.

• Одностраничные приложения (SPA)загружают одну HTML-страницу и динамически обновляют её по мере взаимодействия пользователя с приложением. SPA проще начать использовать, но у них может быть более медленная начальная загрузка. SPA — это архитектура по умолчанию для большинства инструментов сборки.
• Потоковый рендеринг на стороне сервера (SSR)рендерит страницу на сервере и отправляет полностью отрендеренную страницу клиенту. SSR может улучшить производительность, но его настройка и поддержка могут быть сложнее, чем у одностраничного приложения. С добавлением потоковой передачи настройка и поддержка SSR могут стать очень сложными. См.руководство по SSR от Vite.
• Статическая генерация сайтов (SSG)генерирует статические HTML-файлы для вашего приложения во время сборки. SSG может улучшить производительность, но его настройка и поддержка могут быть сложнее, чем у рендеринга на стороне сервера. См.руководство по SSG от Vite.
• React Server Components (RSC)позволяют смешивать компоненты, выполняемые во время сборки, только на сервере и интерактивные компоненты в одном дереве React. RSC может улучшить производительность, но в настоящее время для их настройки и поддержки требуется глубокая экспертиза. См.примеры RSC от Parcel.

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

Использование правильной стратегии рендеринга для правильных маршрутов может уменьшить время, необходимое для загрузки первого байта контента (Time to First Byte), отрисовки первого фрагмента контента (First Contentful Paint) и отрисовки самого крупного видимого контента приложения (Largest Contentful Paint).

И многое другое…

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

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