Структура 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. И правда в том, что вы можете продвинуться довольно далеко без тонны дополнительных библиотек. Но есть несколько основополагающих инструментов, которые могут вывести ваш опыт разработки React на новый уровень. Эти библиотеки решают наиболее распространенные задачи в разработке React, такие как запросы данных с API, стилизация, доступность и управление состоянием, и они делают это минимальным и ненавязчивым способом. Это обеспечивает постепенное внедрение в кодовую базу. Мы составили список из пяти таких библиотек, о которых, по нашему мнению, вам следует знать.

Почему это важно

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

React Query

Проще говоря, React Query делает получение данных в React намного удобнее. Но это не библиотека для получения данных как таковая. Вместо этого это библиотека управления состоянием, которая имеет дело с асинхронным состоянием сервера. Вы предоставляете ей асинхронную функцию, которая затем извлекает данные. useQuery предоставляет вам кучу полезных утилит для обработки асинхронной функции:

• Флаг состояния загрузки
• Кэширование результатов
• Инвалидация и повторный запрос данных

Список небольшой. Но влияние, которое он оказывает на большие кодовые базы, нельзя недооценивать. Как правило, кодовые базы имеют много логики для глобального обмена результатами выборки, их обновления при изменении данных, триггеров для получения данных и многого другого. Большая часть этого просто больше не нужна при использовании React Query. Кэширование означает, что вы можете вызвать хук useQuery по всему приложению, и данные будут совместно использоваться. https://github.com/TanStack/query

Zustand

Каждый React разработчик знает, как сложно шэрить состояние в приложении. При первом столкновении с проблемой вы неизбежно заканчиваете «просверливанием» данных по дереву компонентов (prop drilling). Излишне говорить, что это не делает код чистым и не является устойчивым в долгосрочной перспективе. К счастью, React придумал контекст для решения этой проблемы. Контекст отлично подходит, если все, что вам нужно сделать, это передать несколько значений вниз по дереву компонентов. Но он может стать громоздким для использования в более сложных глобальных сторах. Разработчики должны быть осторожны с последствиями для производительности, и некоторые разработчики не являются большими поклонниками Context API. Zustand предлагает чрезвычайно простой API, который позволяет создавать хранилище со значениями и функциями. Затем вы можете получить доступ к этому хранилищу из любого места в приложении для чтения и записи значений. Реактивность включена. Если вы хотите хранить данные вложенных объектов в своем хранилище, рассмотрите возможность использования Immer вместе с Zustand, чтобы легко изменить вложенное состояние. https://github.com/pmndrs/zustand

Framer Motion

Анимация — один из лучших способов придать вашему React приложению современный вид. Но это непросто. Использование CSS анимации сложно и может привести к большому количеству кода. Напротив, Framer Motion предлагает мощный, но простой API для создания пользовательских анимаций. Он изначально интегрирован в экосистему React с набором хуков и компонентов. Например, этот код - все, что требуется для плавной анимации преобразования из круга в квадрат:

import { motion } from "framer-motion"

export const MyComponent = () => (
  <motion.div
    animate={{
      scale: [1, 2, 2, 1, 1],
      rotate: [0, 0, 270, 270, 0],
      borderRadius: ["20%", "20%", "50%", "50%", "20%"],
    }}
  />
)

Каждое значение в массиве представляет ключевой кадр для соответствующего свойства. Затем анимация проходит через этот цикл. Конечно, вы можете сделать гораздо больше, чем просто определить ключевые кадры с помощью Framer Motion. Вы также можете анимировать изменения в макете, обрабатывать жесты или анимировать на основе прокрутки. https://github.com/framer/motion

Class Variance Authority (CVA)

TailwindCSS быстро превратился в основной способ стилизации приложений React. Но создание многоразовых элементов пользовательского интерфейса с его помощью может быть сложной задачей. Допустим, вы создаете свою собственную кнопку с помощью Tailwind. Так как вы хотите повторно использовать его во всем своем приложении, вы создаете компонент. Но теперь вам нужно несколько вариантов этого компонента. Основной стиль и дополнительный стиль. Итак, теперь вам нужно собрать классы Tailwind вместе в соответствии со значением пропса. Теперь вам также нужны разные цвета и разные размеры для вашей кнопки. Так что добавьте немного пропса и еще больше условной логики, чтобы выяснить правильную комбинацию классов Tailwind. Это может увеличить кодовую базу и усложнить понимание. CVA, сокращение от Class Variance Authority. Это простая библиотека, которая избавляет от необходимости создавать компонуемые компоненты React с именами классов Tailwind. Возьмем этот пример из их документации:

import React from "react";
import { cva, type VariantProps } from "class-variance-authority";

const button = cva("button", {
  variants: {
    intent: {
      primary: [
        "bg-blue-500",
        "text-white",
        "border-transparent",
        "hover:bg-blue-600",
      ],
      secondary: [
        "bg-white",
        "text-gray-800",
        "border-gray-400",
        "hover:bg-gray-100",
      ],
    },
    size: {
      small: ["text-sm", "py-1", "px-2"],
      medium: ["text-base", "py-2", "px-4"],
    },
  },
  compoundVariants: [{ intent: "primary", size: "medium", class: "uppercase" }],
  defaultVariants: {
    intent: "primary",
    size: "medium",
  },
});

export interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof button> {}

export const Button: React.FC<ButtonProps> = ({
  className,
  intent,
  size,
  ...props
}) => <button className={button({ intent, size, className })} {...props} />;

Мы декларативно описываем стили кнопок для каждого значения параметра. Затем CVA выполняет работу по выяснению правильной комбинации стилей. Мы даже можем указать варианты по умолчанию, чтобы сделать определенные свойства необязательными. https://github.com/joe-bell/cva

Radix UI

Если вам нравится создавать полностью кастомизированные пользовательские интерфейсы, но вы не хотите разбираться в тонкостях разработки высококачественных доступных компонентов пользовательского интерфейса с нуля, Radix UI для вас. Библиотека поставляется с различными часто используемыми компонентами пользовательского интерфейса. Например, диалоговые окна, чекбоксы и раскрывающиеся списки. Но с изюминкой. Хотя компоненты содержат всю логику и интерактивность, они не имеют стиля. Это означает, что у вас есть полный контроль над стилизацией компонентов самостоятельно. Это позволяет вам создать действительно настраиваемую систему пользовательского интерфейса, которая не похожа на любой другой веб-сайт. Имея полный контроль над стилем, Radix делает всю остальную работу за вас. Все компоненты полностью доступны - скажем, через навигацию с помощью клавиатуры. Если вам нравится гибкость Radix, но вы не хотите стилизовать все с нуля, вам стоит попробовать shadcn/ui. Это полностью модульная библиотека компонентов, построенная на основе Radix и Tailwind. Вместо того, чтобы устанавливать пакет NPM, вы можете скопировать код непосредственно в свой проект и изменить его по своему вкусу. https://github.com/radix-ui/primitives

Итоги

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