Простой подход к файловым структурам в приложениях React

Типичная постановка проблемы для файловых структур в React проста: «Где лучше всего разместить эту вещь?» Решим эту проблему раз и навсегда!

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

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

Сосредоточьтесь на отношениях файлов (или принципе колокации)

Глядя на проблему через призму команды, а не отдельного человека, начните спрашивать себя, что может быть самым большим конфликтом внутри команды, когда дело доходит до разработки файловой структуры. Вы можете обнаружить, что часто причина, по которой файловую структуру трудно придумать в настройках группы, заключается в конфликте точек зрения, когда дело доходит до того, что куда и как называть папки или файлы. Некоторым может понадобиться, чтобы все компоненты на корневом уровне находились в папке под названием «компоненты». Другие могут выбрать использование «общей» папки, в которой компоненты находятся в папке «компоненты». Вариации бесконечны! Однако, если мы отойдем от потребностей или проблем человека, пишущего код, и посмотрим на взаимосвязь внутри кода, мы сможем начать разработку файловой структуры, которая просто имеет смысл.

Подход

Давайте посмотрим на пример файловой структуры, в которой используются отношения. Примечание. В этом конкретном примере для управления состоянием используется Typescript и Redux, но его можно применить к приложениям React с помощью Javascript. Просто замените расширения файлов .ts/.tsx на .js/.jsx.

.
├── actions
│   ├── index.ts
│   └── someAction
│       ├── someAction.test.ts
│       └── someAction.ts
├── components
│   ├── SomeComponent
│   │   ├── SomeComponent.test.tsx
│   │   ├── SomeComponent.tsx
│   │   └── someComponent.scss
│   └── index.ts
├── constants
│   ├── index.ts
│   └── someFeature.ts
├── containers
│   ├── dashboard
│   │   ├── Dashboard.test.tsx
│   │   ├── Dashboard.tsx
│   │   └── dashboard.scss
│   └── login
│       ├── Login.test.tsx
│       ├── Login.tsx
│       ├── components
│       │   ├── SomeComponent
│       │   │   ├── SomeComponent.test.tsx
│       │   │   ├── SomeComponent.tsx
│       │   │   └── someComponent.scss
│       │   └── index.ts
│       └── login.scss
├── fonts
│   └── SomeFont.ttf
├── reducers
│   ├── index.ts
│   └── someReducer
│       ├── someReducer.test.ts
│       └── someReducer.ts
├── styles
│   ├── animations.scss
│   ├── index.scss
│   └── variables.scss
├── types
│   ├── index.ts
│   └── someFeature.ts
└── utils
    ├── index.ts
    └── someUtil.ts

Выводы

  1. Код размещен в одном месте
    Если мы исследуем способ, которым actions папка или reducers структурирована, мы быстро поймем, что эти папки содержат все наши редукторы и действия, но они сами по себе отдельные папки. Это потому, что для этого примера, хотя все редукторы и действия влияют на приложение глобально, каждый из них является своим собственным модулем, поэтому каждый из них находится в своей собственной подпапке. У них есть свои тесты и они занимаются конкретным делом. Подумайте об этом так, как это может относиться к рабочей среде разработки: все разработчики находятся в одном здании (глобальная папка), но каждый из них придерживается своего рабочего стола, группы приложений или функционального подразделения (подпапки), и у каждого из них есть свои собственные ноутбуки, клавиатуры или мониторы (файлы).
  2. Код, который связан с более чем одним другим фрагментом кода (или вы можете думать об этом как о коде в одном файле по отношению к коду в другом файле), находится на корневом уровне
    Автор делая это, мы можем сигнализировать тому, кто берет этот код и запускает его, что каждая из этих вещей, которые существуют на самом высоком уровне, просачиваются в более чем одно место приложения.
    Это но не только на корневом уровне. Если мы исследуем, что происходит в папке containers (может быть переименовано в pages, views и т. Д. В зависимости от ваших предпочтений), мы также заметим, что имеет место отношение инкапсуляции. Внутри находится еще одна components папка. Каждый из компонентов, которые уникально составляют этот конкретный контейнер, является важной функцией, которая будет использоваться только в этом контейнере и нигде больше. Связь очевидна; если эти компоненты находились снаружи на корневом уровне приложения, но когда-либо использовались только в одном контейнере, вы можете задаться вопросом, почему обход папки сложнее, чем должен быть, или почему он разделяет пространство с вещами , к которому он не имеет отношения.
  3. Вложенность не должна быть проблемой
    В примере представлена ​​файловая структура приложения React, которая имеет не более трех уровней вложенности в каждой глобальной папке, что полезно, чтобы вы не заблудились, но иллюстрирует побочный эффект простоты применения структуры сначала отношения. Если мы сделаем наши компоненты простыми, наша папка контейнеров, самая глубокая вложенная, никогда не будет глубже, чем на три уровня.
  4. Индексные файлы присутствуют для чистого импорта
    Честно говоря, это просто полезно. Если вы используете псевдонимы для импорта, это может не понадобиться.

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

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

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

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

[1]: Реагировать на документы