Структура React приложения

Не существует единого мнения о том, как правильно организовать React-приложение. React дает вам много свободы, но вместе с этой свободой приходит ответственность за выбор собственной архитектуры. Часто бывает так, что тот, кто создает приложение в самом начале, сваливает почти все в папку components. Но есть способ получше. Нужно подходить к организации своих приложений обдуманно, чтобы их было легко использовать, понимать и расширять. В этой статье рассмотрим вариант структуры Реакт приложения, который интуитивно понятен и может масштабироваться с ростом React приложения. Основная концепция, заключается в том, чтобы сделать архитектуру ориентированной на функциональность, а не на типы. Организовать только общие компоненты на глобальном уровне и собрать в один модуль все остальные связанные сущности вместе.

Технологии

Поскольку эта статья будет носить характер мнения. Сделаем несколько предположений о том, какие технологии будут использоваться в проекте:

• Приложение - React (Hooks)
• Глобальное управление состоянием - Redux, Redux Toolkit
• Маршрутизация - React Router
• Стили - CSS, Sass, Styled Components
• Тестирование - Jest, React Testing Library

Нет четкого мнения по поводу стилей, идеальны ли Styled Components, CSS-модули или пользовательский набор для Sass, поэтому можно использовать любой подходящий вариант. Также предполагается, что тесты находятся рядом с кодом, а не в папке tests на верхнем уровне. Все, что здесь написано, может быть применимо, если вы используете обычный Redux, а не Redux Toolkit. Можно настроить ваш Redux как feature slices. Также будет удобно визуализировать созданные компоненты с помощью, например, Storybook. Также покажем, как проект будет выглядеть с этими файлами, если вы решите использовать его в своем проекте. Для примера будем использовать приложение “Библиотека”, который имеет страницу со списком книг, страницу со списком авторов и систему аутентификации.

Структура каталога

Структура каталогов верхнего уровня будет выглядеть следующим образом:

• assets - глобальные статические файлы, такие как изображения, svg, логотип компании и т.д.
• components - глобальные общие/повторно используемые компоненты, такие как макеты (обертки), компоненты форм, кнопки
• services - JavaScript модули
• store - глобальное хранилище Redux
• utils - утилиты, помощники, константы и т.п.
• views - можно также назвать pages, здесь будет содержаться большая часть приложения. Лучше сохранять привычные соглашения, где это возможно, поэтому src содержит все, index.js является точкой входа, а App.js устанавливает аутентификацию и маршрутизацию.

.
└── /src
    ├── /assets
    ├── /components
    ├── /services
    ├── /store
    ├── /utils
    ├── /views
    ├── index.js
    └── App.js

Также в проекте могут присутствовать некоторые дополнительные папки, которые у вас могут быть, такие как types, если это проект TypeScript, middlewares (промежуточное программное обеспечение), если необходимо, возможно, контекст для работы с Context API и т.д.

Псевдонимы (алиасы)

Полезно настроить систему на использование псевдонимов, чтобы все, что находится в папке компонентов, можно было импортировать как @components, изображения как @assets и т. д. Если у вас Webpack, это делается через конфигурацию resolve.

module.exports = {
  resolve: {
    extensions: ['js', 'ts'],
    alias: {
      '@': path.resolve(__dirname, 'src'),
      '@assets': path.resolve(__dirname, 'src/assets'),
      '@components': path.resolve(__dirname, 'src/components'),
      // ...etc
    },
  },
}

Это просто облегчает импорт из любого места в проекте и перемещение файлов без изменения импорта, и вы никогда не получите что-то вроде ../../../../../../../components/.

Компоненты

В папке components компоненты сгруппированы по типам - формы, таблицы, кнопки, макеты и т.д. Специфика зависит от конкретного приложения. В данном примере предполагается, что вы либо создаете собственную систему форм, либо создаете привязку к существующей системе форм (например, комбинируя Formik и Material UI). В этом случае вы создадите папку для каждого компонента (TextField, Select, Radio, Dropdown и т.д.), а внутри будет файл для самого компонента, стили, тесты и Storybook, если он используется.

• Component.js - собственно компонент React
• Component.styles.js - файл стилей для компонента
• Component.test.js - тесты
• Component.stories.js - файл Storybook.

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

.
└── /src
    └── /components
        ├── /forms
        │   ├── /TextField
        │   │   ├── TextField.js
        │   │   ├── TextField.styles.js
        │   │   ├── TextField.test.js
        │   │   └── TextField.stories.js
        │   ├── /Select
        │   │   ├── Select.js
        │   │   ├── Select.styles.js
        │   │   ├── Select.test.js
        │   │   └── Select.stories.js
        │   └── index.js
        ├── /routing
        │   └── /PrivateRoute
        │       ├── /PrivateRoute.js
        │       └── /PrivateRoute.test.js
        └── /layout
            └── /navigation
                └── /NavBar
                    ├── NavBar.js
                    ├── NavBar.styles.js
                    ├── NavBar.test.js
                    └── NavBar.stories.js

Обратите внимание, что в каталоге components/forms есть файл index.js. Часто справедливо советуют избегать использования файлов index.js, поскольку они не являются явными, но в данном случае это имеет смысл - в конечном итоге он будет индексом всех форм и будет выглядеть примерно так:

// src/components/forms/index.js

import { TextField } from './TextField/TextField'
import { Select } from './Select/Select'
import { Radio } from './Radio/Radio'

export { TextField, Select, Radio }

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

import { TextField, Select, Radio } from '@components/forms'

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

Сервисы

Каталог services менее важен, чем компоненты, но если вы создаете простой модуль JavaScript, который используется остальной частью приложения, он может быть полезен. Обычный пример - модуль LocalStorage, который может выглядеть следующим образом:

.
└── /src
    └── /services
        ├── /LocalStorage
        │   ├── LocalStorage.service.js
        │   └── LocalStorage.test.js
        └── index.js

Пример сервиса:

// src/services/LocalStorage/LocalStorage.service.js
export const LocalStorage = {
  get(key) {},
  set(key, value) {},
  remove(key) {},
  clear() {},
}

import { LocalStorage } from '@services'

LocalStorage.get('foo')

Хранилище (стор, store)

Глобальное хранилище данных будет содержаться в директории store - в данном случае Redux. Каждая функциональность будет иметь свою папку, в которой будет содержаться слайс Redux Toolkit, а также экшены и тесты. Эта настройка также может быть использована с обычным Redux, вы просто создадите файл .reducers.js и .actions.js вместо slice. Если вы используете саги, это может быть .saga.js вместо .actions.js для действий Redux Thunk.

.
└── /src
    ├── /store
    │   ├── /authentication
    │   │   ├── /authentication.slice.js
    │   │   ├── /authentication.actions.js
    │   │   └── /authentication.test.js
    │   ├── /authors
    │   │   ├── /authors.slice.js
    │   │   ├── /authors.actions.js
    │   │   └── /authors.test.js
    │   └── /books
    │       ├── /books.slice.js
    │       ├── /books.actions.js
    │       └── /books.test.js
    ├── rootReducer.js
    └── index.js

Вы также можете добавить что-то вроде ui секции стора для обработки модальных окон, всплывающих уведомлений, переключения боковой панели и других глобальных состояний пользовательского интерфейса, что, лучше, чем иметь const [isOpen, setIsOpen] = useState(false) повсюду. В rootReducer вы импортируете все свои фрагменты и объединяете их с помощью combineReducers, а в index.js настраиваете магазин.

Утилиты (Utils)

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

.
└── src
    └── /utils
        ├── /constants
        │   └── countries.constants.js
        └── /helpers
            ├── validation.helpers.js
            ├── currency.helpers.js
            └── array.helpers.js

Опять же, папка utils может содержать все, что вы захотите, и что, по вашему мнению, имеет смысл держать на глобальном уровне. Если вам не нравятся "многоуровневые" имена файлов, вы можете просто назвать его validation.js. Однако, это облегчает навигацию по именам файлов при поиске в IDE.

Views

Здесь находится основная часть вашего приложения: в каталоге views. Любая страница в вашем приложении - это "представление" (view). В этом небольшом примере представления довольно хорошо согласуются со стором Redux, но не обязательно, что стор и представления будут полностью совпадать, поэтому они разделены. Кроме того, книги могут тянуть за собой авторов, и так далее. Все, что находится внутри представления, является сущностью, которая, скорее всего, будет использоваться только в этом конкретном представлении - BookForm, который будет использоваться только на маршруте /books, и AuthorBlurb, который будет использоваться только на маршруте /authors. Это могут быть специфические формы, модальные окна, кнопки, любые компоненты, которые не будут глобальными. Преимущество хранения всего в домене вместо объединения всех страниц в компоненты/страницы заключается в том, что это позволяет легко взглянуть на структуру приложения и узнать, сколько в нем представлений верхнего уровня, и понять, где находится все, что используется только этим представлением. Если есть вложенные маршруты, вы всегда можете добавить папку вложенных представлений в основной маршрут.

.
└── /src
    └── /views
        ├── /Authors
        │   ├── /AuthorsPage
        │   │   ├── AuthorsPage.js
        │   │   └── AuthorsPage.test.js
        │   └── /AuthorBlurb
        │       ├── /AuthorBlurb.js
        │       └── /AuthorBlurb.test.js
        ├── /Books
        │   ├── /BooksPage
        │   │   ├── BooksPage.js
        │   │   └── BooksPage.test.js
        │   └── /BookForm
        │       ├── /BookForm.js
        │       └── /BookForm.test.js
        └── /Login
            ├── LoginPage
            │   ├── LoginPage.styles.js
            │   ├── LoginPage.js
            │   └── LoginPage.test.js
            └── LoginForm
                ├── LoginForm.js
                └── LoginForm.test.js

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

Итоги

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

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

Основные принципы React

В основе React лежит набор основных принципов. Понимание этих принципов является ключом к созданию масштабируемых, поддерживаемых приложений React. Одним из наиболее фундаментальных принципов React является концепция «однонаправленного потока данных». Это означает, что данные проходят через приложение в одном направлении, от родительских компонентов до дочерних компонентов. Структурируя приложение таким образом, можно создать четкий и предсказуемый поток данных, упрощающий управление кодом и его отладку. Другим основным принципом React является использование «виртуальной модели DOM» (Document Object Model). Виртуальный DOM представляет собой абстракцию собственной модели DOM браузера, которая позволяет React более эффективно обновлять пользовательский интерфейс, сводя к минимуму количество требуемых фактических обновлений DOM. Используя виртуальный DOM, React может обновлять пользовательский интерфейс быстрым и отзывчивым способом, не требуя ненужных повторных отрисовок или обновлений.

Рекомендации по структурированию и организации кода

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

Компонентная архитектура

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

Разделение ответственности

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

Повторное использование кода

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

Масштабируемая структура папок

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

Инструменты и методы оптимизации производительности и масштабируемости

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

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

Отрисовка на стороне сервера (SSR) может помочь сократить время начальной загрузки приложения, отрендерив исходный HTML-код на сервере, а не ожидая, пока клиент загрузит и запустит JavaScript. Это может привести к более быстрому взаимодействию с пользователем, особенно в более медленных сетях или устройствах.

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

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

Мемоизация

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

Профилирование производительности

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

Автоматизированное тестирование

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