По сути, контейнеры являются коннекторами к стору. Они лишь пробрасывают пропсы, хотя иногда в них есть lifecycle-хуки.

Разделение сущности порождает проблему: поменяли контейнер, сразу же побежали менять компонент.

Я взял методологию @AtomicDesign и наложил её на подходы в react-redux.

Каждая страница:
- отвечает за один адрес в роутинге
- имеет всю связанную логику в одном файле
- экспортирует чистый компонент и приконнекченный

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

В итоге, в одном файле мы имеем весь код необходимый для охвата одной страницы целиком.

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

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

Чтобы избежать суперкомпонентов есть два подхода:
- выбирать данные пачками из стора и прокидывать целиком в компоненты из страницы
- подключать организмы к стору (в фичах)

Я стараюсь описывать всю логику страницы в файле этой самой страницы.

Также свожу количество коннектов компонентов к минимуму, чем меньше коннектов, тем очевиднее код. Обычно приконнекчены только страницы.

@AtomicDesign

Это методология создания дизайн систем. По факту это язык общения дизайнера и разработчика.

http://atomicdesign.bradfrost.com

В контексте feature slices, к UI стоит относиться как ко внешней библиотеке компонентов. То есть импортировать в ui кишки приложения явно не стоит.

Все компоненты делятся на 5 различных уровней.

Компоненты одного уровня могут импортировать только компоненты уровнем ниже. Исключение: organisms, templates.

Каждый компонент должен делать что-то одно и делать это хорошо.
Компоненты в системе должны хорошо работать вместе.

Атомы — простейшие компоненты, без какой-либо логики. Базовые строительные блоки для всей остальной системы.

Атомами могут быть даже такие абстрактные единицы как цвета, шрифты, анимации, …

Молекулы — это композиция атомов, стилей и простейших условий. Основа дизайн системы.

Например, сами по себе label, input или button не являются полезными компонентами. Но объединив их вместе, можно получить бизнес-сущность с конкретной целью.

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

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

Организмы могут содержать в себе сложное внутренне состояние, опциональный рендеринг и свои стили.

Если организм лежит в фиче, он также может быть подключен к стору.

Шаблон — это своего рода макет, скетч будущей страницы. Он определяет разметку компонентов.

Отвечает за отображение компонентов на странице.
Обычно содержит media-query и не содержит бизнес-логики.

В реакте это своеобразные компоненты с “дырками”.

Шаблоны заполняются в компонентах страниц.

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

Такой подход позволяет изменять разметку сразу нескольких страниц, не меняя кучу файлов. А также изменить разметку одной страницы не добавляя условий в вышестоящие компоненты (полезно для A/B тестирования).

Страница — инстанс конкретного набора шаблонов.

Страницы это именно то, что видит пользователь переходя по какому-то адресу.

Обычно файлы исходного кода страниц плоские и длинные.

Стоит заметить, что страницы есть только в фичах, в UI их быть не может.

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

features/ — набор сущностей
features/name — одна сущность
./pages/ — набор сущностей

с файлами похожая штука
./reducer.js — одна сущность
./actions.js — набор сущностей

Вложение директорий определяется вложением сущностей.

— как понять, что есть сущность, а что нет?
— нужно определиться, можно ли с “этим” работать не погружаясь в детали. Можно ли к “этому” обращаться как единой цельной структуре?

страница регистрации сущность? Мы можем ее заимпортить как цельную сущность — да. Можем изменить именно эту страницу — да. Страница цельная сама по себе — да.

ui — сущность? мы можем заимпортить ui и работать с ним в коде — да. Можно ли к нему обращатсья как к цельной структуре — нет(он не несет в себе функциональности, только его части по отдельности ее имеют).