Фрактальная структура проекта с React и Redux - за/против

Я хотел бы знать, каковы плюсы и минусы использования фрактальной структуры в проекте React + Redux, и мне было интересно, есть ли у кого-нибудь опыт в этом подходе или имеются ли подводные камни, не видны сразу из документов.

(Фрактальная структура) Также известна как: Self-Contained Apps, Иерархия рекурсивного маршрута, Провайдеры и т.д.

Контекст: Я смотрю react-redux-starter-kit и предлагает использовать фрактальную структуру для организации папок. Если я правильно понял, этот подход требует организации папок проекта по функции и рекурсивно вложенного маршрута.

Итак, если у меня есть ресурсы событий, где

/events перечислены все события

/events/new показать форму для вставки нового события

/events/1/details показать информацию о событии с id 1

Начиная с шаблона, я должен добавить новую папку маршрута, например:

├── src # Application source code │ ├── main.js # Application bootstrap and rendering │ ├── components # Reusable Presentational Components │ ├── containers # Reusable Container Components │ ├── layouts # Components that dictate major page structure │ ├── static # Static assets (not imported anywhere in source code) │ ├── styles # Application-wide styles (generally settings) │ ├── store # Redux-specific pieces │ └── routes # Main route definitions and async split points │ ├── index.js # Bootstrap main application routes with store │ ├── Root.js # Wrapper component for context-aware providers ~ ~ │ ├── Events # Fractal route │ │ ├── index.js # Route definitions and async split points │ │ ├── components # Presentational React Components │ │ ├── container # Connect components to actions and store │ │ ├── modules # Collections of reducers/constants/actions or single DUCK module │ │ └── routes # Fractal sub-routes (** optional) <------------- │ │ │ │ │ └── New │ │ │ ├── index.js # Route definitions and async split points │ │ │ ├── assets # Assets required to render components │ │ │ ├── components # Presentational React Components │ │ │ ├── container # Connect components to actions and store │ │ │ ├── modules # Collections of reducers/constants/actions or single DUCK module │ │ │ └── routes # Fractal sub-routes (** optional) <------------- │ │ │ │ │ └── Details │ │ ├── index.js # Route definitions and async split points │ │ ├── assets # Assets required to render components │ │ ├── components # Presentational React Components │ │ ├── container # Connect components to actions and store │ │ ├── modules # Collections of reducers/constants/actions or single DUCK module │ │ └── routes # Fractal sub-routes (** optional) <------------- ~ ~ │ └── NotFound # Capture unknown routes in component ~

С папкой New и Details, вложенной в корневую папку Event.

Документы выделяют основные профи:

Он масштабируется лучше, чем плоская структура каталогов, с папками для компоненты, контейнеры и т.д.

Маршруты могут быть объединены в "куски" с использованием алгоритма разбиения и слияния кода веб-пакета

Поскольку логика является автономной, маршруты можно легко разбить на отдельные репозитории и ссылки с помощью webpack DLL plugin для гибких, высокопроизводительная разработка и масштабируемость.

Ответы

Ответ 1

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

Например, скажите, что вы получаете требование о том, чтобы на вашем стартовом маршруте вы показывали детали для самого последнего события.

теперь он выглядит так:

routes
├─Events
│     ├─New
│     ├─Details
├─StartPage
       ├─ components   // here somewhere you import ../../Events/Details

Это не конец света, но ваша хорошая иерархия уже не так строго иерархична.

Ответ 2

Единственным недостатком, с которым я могу поговорить, не может at a glance просматривать все доступные маршруты и их соответствующие компоненты, это можно смягчить, сделав некоторые описательные комментарии, но это увеличивает сложность конфигурации вашего маршрута. Я также попытался бы сохранить вложенные папки до минимума, поскольку существует когнитивная нагрузка, связанная с получением уровней вложенности в ваших операциях импорта i.e ../../../../../ они могут выйти из-под контроля, если у вас много вложенных маршрутов.