Структура React приложения
2 года назад·6 мин. на чтение
Как структурировать React приложение и как организовать React приложение.
Не существует единого мнения о том, как правильно организовать React-приложение. React дает вам много свободы, но вместе с этой свободой приходит ответственность за выбор собственной архитектуры. Часто бывает так, что тот, кто создает приложение в самом начале, сваливает почти все в папку
Обратите внимание, что в каталоге
components
. Но есть способ получше. Нужно подходить к организации своих приложений обдуманно, чтобы их было легко использовать, понимать и расширять.
В этой статье рассмотрим вариант структуры Реакт приложения, который интуитивно понятен и может масштабироваться с ростом React приложения. Основная концепция, заключается в том, чтобы сделать архитектуру ориентированной на функциональность, а не на типы. Организовать только общие компоненты на глобальном уровне и собрать в один модуль все остальные связанные сущности вместе.
Технологии
Поскольку эта статья будет носить характер мнения. Сделаем несколько предположений о том, какие технологии будут использоваться в проекте:- Приложение - React (Hooks)
- Глобальное управление состоянием - Redux, Redux Toolkit
- Маршрутизация - React Router
- Стили - CSS, Sass, Styled Components
- Тестирование - Jest, React Testing Library
tests
на верхнем уровне.
Все, что здесь написано, может быть применимо, если вы используете обычный Redux, а не Redux Toolkit. Можно настроить ваш Redux как feature slices.
Также будет удобно визуализировать созданные компоненты с помощью, например, Storybook. Также покажем, как проект будет выглядеть с этими файлами, если вы решите использовать его в своем проекте.
Для примера будем использовать приложение “Библиотека”, который имеет страницу со списком книг, страницу со списком авторов и систему аутентификации.
Структура каталога
Структура каталогов верхнего уровня будет выглядеть следующим образом:assets
- глобальные статические файлы, такие как изображения, svg, логотип компании и т.д.components
- глобальные общие/повторно используемые компоненты, такие как макеты (обертки), компоненты форм, кнопкиservices
- JavaScript модулиstore
- глобальное хранилище Reduxutils
- утилиты, помощники, константы и т.п.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
- собственно компонент ReactComponent.styles.js
- файл стилей для компонентаComponent.test.js
- тестыComponent.stories.js
- файл 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 приложения, удобна для тестирования и стилизации, а также сохраняет все вместе в функционально ориентированном виде. Она более вложенная, чем традиционная структура, в которой все находится в компонентах и контейнерах. Легко взглянуть на эту систему и понять, что нужно для вашего приложения и куда идти, чтобы поработать над конкретным разделом или компонентом, который влияет на приложение глобально.9 вопросов для собеседования, которые должен знать каждый Senior React разработчик
2 года назад·7 мин. на чтение
Как React разработчик, вы в конечном итоге почувствуете желание сделать следующий большой шаг к роли senior разработчика. Конечно, опыт приходит со временем, но некоторые могут иметь мышление senior разработчика, но упускать из поля изучения необходимые темы.
Вот несколько очень распространенных вопросов на собеседовании, которые вам могут задать во время собеседования на должность сеньор React разработчика.
1. Можете ли вы описать ситуацию, когда вам пришлось оптимизировать React приложение, чтобы повысить его производительность? Как вы это сделали?
Как кандидат на должность senior React разработчика, от вас ожидают, что вы будете знать, как оптимизировать приложение React для повышения производительности. Понимание жизненного цикла React и хуков может помочь в этом. Некоторые способы оптимизации производительности React приложения могут включать следующее:- Избегать ненужных повторных рендеров
- Использовать уникального идентификаторы при отображении списков
- Использование хуков, таких как
useMemo
иuseCallback
, для запоминания функций
2. Как вы справляетесь с управлением состоянием в большом React приложении?
В React есть два типа состояния. Локальное и глобальное состояние. Локальное состояние является исключительным для области действия компонента React. Доступ к глобальному состоянию может получить любой из ваших компонентов. Некоторые распространенные библиотеки для управления состоянием в большом реакт приложении включают:Когда использовать состояние?
Представьте, что вы создаете приложение со списком дел в React. Вы хотите отслеживать список задач, которые ввел пользователь, а также логическое значение, указывающее, загружает ли приложение в данный момент данные из API. Например, у вас может быть действие с именемADD_TODO
, которое добавляет новый элемент списка дел в массив, и редьюсер, который соответствующим образом обновляет состояние. У вас также может быть действие SET_LOADING
, которое обновляет состояние загрузки.
Другим примером может быть корзина для покупок, которая отслеживает товары внутри корзины, даже когда пользователь обновляет страницу или покидает ее.
Если ваши данные передаются только из глобальной переменной в компоненты приложения, вы также можете реализовать хук useContext
. Это хорошо работает для работы с темами интерфейса пользователя и реализации аутентификации.
3. Можете ли вы описать опыт работы со сложной структурой данных в приложении React? Как вы с этим справились?
Для работы со сложными структурами данных в приложении React вам может потребоваться использовать такие методы, как сопоставление вложенных данных (маппинг, mapping), использование рекурсивных компонентов для визуализации данных с несколькими уровнями вложенности и оптимизация производительности с помощью таких методов, какReact.memo
.
Также может быть полезно использовать библиотеки, такие как lodash
, для управления и преобразования сложных структур данных. Например, функция debounce
из библиотеки lodash
, полезна для сокращения количества API запросов.
Очевидно, что в React существует множество способов обработки сложных структур данных. Вот несколько сценариев, в которых вам, возможно, придется более осторожно подходить к обработке и представлению данных.
- Вложенные структуры данных, такие как дерево или граф.
- Большие наборы данных, которые необходимо отображать и обрабатывать в виде таблицы или списка.
- Структуры данных со многими уровнями вложенности, например, объект JSON с несколькими уровнями вложенных объектов и массивов.
- Структуры данных, которые постоянно меняются, например, данные в режиме реального времени из прямой трансляции или подключения через веб-сокет.
4. Как вы подходите к тестированию приложения React?
Важно иметь хорошую стратегию тестирования, чтобы убедиться, что ваше приложение React стабильно и работает правильно. Это может включать в себя комбинацию модульных тестов, интеграционных тестов и E2E тестов, а также такие методы, как снэпшот (snapshot) тестирование и TDD (разработка через тестирование).- Используйте встроенные утилиты тестирования React, такие как React Testing Library и Enzyme, для проверки рендеринга и поведения компонентов.
- Напишите модульные тесты для отдельных компонентов React, чтобы убедиться, что они работают правильно изолированно.
- Напишите интеграционные тесты, чтобы проверить взаимодействие между несколькими компонентами и убедиться, что они правильно работают вместе.
- Используйте фреймворк для тестирования, такой как Jest, для запуска и организации тестов.
- Используйте снэпшот тестирование, чтобы убедиться, что рендеринг вашего компонента неожиданно не изменится.
- Используйте разработку через тестирование (TDD) для написания тестов перед написанием реализацией функций.
- Используйте библиотеку для мокирования, такую как Sinon.js, для мокирования зависимостей в ваших тестах.
- Напишите e2e тесты для тестирования приложения в целом, имитируя взаимодействие пользователя в реальном браузере.
5. Как вы обрабатываете асинхронные действия в React приложении?
Один из способов — использовать ключевые словаasync
и await
, которые позволяют писать асинхронный код в синхронном стиле.
Вот пример компонента, который выполняет асинхронный вызов API с использованием async
и await
:
.
Другой способ обработки асинхронных функций в React — использование библиотеки, такой какimport React, { useState, useEffect } from 'react'; function MyComponent() { const [data, setData] = useState(null); useEffect(() => { async function fetchData() { const response = await fetch('https://example.com/get-data'); const data = await response.json(); setData(data); } fetchData(); }, []); return ( <div> {data ? ( <div>{data.message}</div> ) : ( <div>Loading...</div> )} </div> ); }
axios
или fetch
, для выполнения API вызовов. Вот пример использования axios
:
Подробнее об асинхронности можно прочитать в статье Полное руководство по асинхронному JavaScriptimport React, { useState, useEffect } from 'react'; import axios from 'axios'; function MyComponent() { const [data, setData] = useState(null); useEffect(() => { async function fetchData() { const response = await axios.get('https://example.com/get-data'); setData(response.data); } fetchData(); }, []); return ( <div> {data ? ( <div>{data.message}</div> ) : ( <div>Loading...</div> )} </div> ); }
6. Можете ли вы рассказать об отличиях между презентационным и контейнерным компонентами в React?
В React презентационные компоненты связаны с тем, как все выглядит, а контейнерные компоненты — с тем, как все работает. Презентационные компоненты обычно отвечают за отрисовку элементов пользовательского интерфейса на экране. Они получают данные и обратные вызовы в качестве пропсов. Обычно они сосредоточены на рендеринге JSX и не знают о состоянии или действиях приложения. Вот пример презентационного компонента:Компоненты-контейнеры обычно отвечают за управление состоянием и действиями. Они содержат логику для выборки данных, обработки пользовательского ввода и выполнения других задач. Они знают о состоянии и действиях приложения и передают данные и обратные вызовы презентационным компонентам через пропсы. Вот пример компонента-контейнера:import React from 'react'; function Button(props) { return <button>{props.label}</button>; }
Разделение презентационных и контейнерных компонентов может помочь упростить понимание, тестирование и поддержку вашего кода за счет отделения задач, связанных с тем, как вещи выглядят, от того, как они работают.import React, { Component } from 'react'; import Button from './Button'; class Form extends Component { state = { name: '', }; handleChange = (event) => { this.setState({ name: event.target.value }); }; handleSubmit = (event) => { event.preventDefault(); // отправка формы }; render() { return ( <form onSubmit={this.handleSubmit}> <label> Name: <input type="text" value={this.state.name} onChange={this.handleChange} /> </label> <Button label="Submit" /> </form> ); } }
7. Можете ли вы описать, как бы вы реализовали пагинацию в приложении React?
Вот один из способов реализации функции пагинации (перехода по страницам) в приложении React:- Определите общее количество необходимых страниц, исходя из объема имеющихся у вас данных и количества элементов, которые вы хотите отобразить на странице.
- Добавьте переменную состояния
page
в свой компонент, чтобы отслеживать текущую страницу. - Напишите функцию, которая извлекает данные для определенной страницы и обновляет состояние компонента новыми данными.
- Отобразите интерфейс пагинации, который может включать кнопки для перехода к следующей и предыдущей страницам, а также раскрывающийся список для выбора конкретной страницы.
- Добавьте обработчики событий для элементов компонента пагинации, которые вызывают функцию выбора с соответствующим номером страницы.
8. Как вы обрабатываете роутинг на стороне клиента в приложении React?
Существует несколько способов обработки маршрутизации на стороне клиента в приложении React. Одним из популярных способов является использование библиотекиreact-router-dom
, которая предоставляет компонент <Router>
для обработки маршрутизации и набор компонентов <Route>
для определения маршрутов в вашем приложении.
Вот пример того, как вы можете использовать react-router-dom
для обработки маршрутизации на стороне клиента в приложении React:
Установите библиотеку react-router-dom
.
Импортируйте компонентыnpm install react-router-dom
<Router>
и <Route>
из react-router-dom
.
Оберните свое приложение компонентомimport { BrowserRouter as Router, Route } from 'react-router-dom';
<Router>
.
Определите маршруты с помощью компонента<Router> <App /> </Router>
<Route>
. Компонент <Route>
принимает проп path
, указывающее путь для маршрута, и проп component
, указывающий компонент для отображения при совпадении маршрута.
Компонент<Route exact path="/" component={Home} /> <Route path="/about" component={About} /> <Route path="/users/:id" component={User} />
<Route>
будет отображать указанный компонент, когда текущий URL-адрес соответствует пути маршрута. Вы можете использовать проп exact
, чтобы указать, что маршрут должен сопоставляться только тогда, когда путь точно совпадает с текущим URL-адресом.
Вы также можете использовать компонент <Link>
из react-router-dom
для создания ссылок, которые перемещаются между маршрутами в вашем приложении.
import { Link } from 'react-router-dom'; ... <Link to="/about">About</Link>