Альтернативный гайд click
Пример реального проекта click
components/
atoms/
Button/
Icon/
Shadow/
molecules/
UserAvatar/
index.js
UserAvatar.jsx
organisms/
UserSearch/
templates/
UserPage
pages/
UserProfilePage
containers/
UserProfile
ArticleList
services/
api/
user/
article
validation/
userForm
articleItemForm
store/
user/
reducer.js
actions.js
selectors.js
middlewares.js
index.js
article/
reducer.js
actions.js
index.js
modules/
dashboard/
components/
Hero/
Footer/
PagesGrid/
containers/
PagesGrid/
store/
actions.js
reducers.js
index.js
Папка с компонентами должна по максимум отображать ui-kit который используют дизайнеры для того, что бы разработчики и дизайнеры общались на одноv и том же языке компонентов. Такой подход упрощает разработку и проектирование.
Рутовые components представляют собой ui-kit проекта. Компоненты организованы через atomic design.
- Атом - строительный блок проекта. Минимальная строительная единица которая Атомом может быть только самый простой елемент который не содержит в себе ничего другого кроме минимального представления. Пример компонентов: инпут, кнопка, иконка.
- Молекула - Елемент который собирает в себя другие атомы и молекулы и может
иметь ui логику под капотом. Например молекулой может быть инпут с поиском, а
ui логика в, нашем случае, это дополнительный handler
по иконке очистить инпут. Пример компонентов: инпут с поиском, кнопки для пагинаций, card с картинкой и кнопками, картинка с состояниями загрузки изображения - Организмы - это набор атомов и молекул который представляет собой ui какой-то сущности со своей ui логикой. Т.е организмом можно назвать инпут поиска с подсказками при поиские и лоадером для загрузки этих подсказок. При этом он может иметь какое-то локальное ui состояние. Организм может собой представлять как связанные логически между собой компоненты, так и набор компонентов которые связаные между собой только визуально. Пример компонентов: Инпут с подсказками, кнопкой поиска, и кнопкой очистить, группа инпутов, список с елементами и поиском по них.
- Шаблоны - это layout какого-то блока на странице, который знает как организовывать(куда и когда пихать) компоненты. Пример компонентов: шаблон блока для дешборда, шаблон странички для редактирования профиля юзера.
- Страницы - Страница это полноцення ui бизнес сущность в которая испльзует нужный шаблон и прокидывает туда нужные организмы и молекулы. Примеры компонентов: Полноценная страница юзера для просмотра профиля. Страница галлереи с разными лаяутами и переключалкой
Правила по написанию таких компонентов
- Они должны быть максимально чистыми
- Они должны быть максимально простыми в использовании, но также должна быть возможность настроить их под себя по максимуму.
- Они не должны иметь никакой бизнес логики.
- Они не должны подключаться к какому либо из store (redux/mobx)
Контейнеры это наши бизнес сущности. Контейнеры имеют доступ к store, они могут вызывать actions. Они знают куда и когда делать запрос на получение данных. И когда отображать какой-то из компонентов. Контейнеру желательно использовать только компоненты с ui-kit (папка components). Контейнер для страницы юзера будет передавать нужные данные для отображения в шаблон страницы юзера и при нажатии на кнопку реактирования покажет другой шаблон для редактирования данных юзера. Но очень часто бывает, что при очень большом количестве логики для отображения, валидации и тд. Обязаности шаблона смещаются к контейнеру и он выполняет функцию шаблона. Такое часто бывает когда ui логика очень специфическая или очень тесно связана с бизнес логикой. Например специфические анимации при неправильном вводе никнейма для пользователя или невалидной почте.
Контейнеры так же могут содержать специфические ui компонены. Такие компоненты можно создавать в подпапке components контейнера или на уровне с контейнером. При создании таких компонентов стоит хорошо обдумать.
Могут ли переиспользоваться такие компоненты ?
да - делает их переиспользуемыми и кастомизируем в папке с контейнером
нет - можно ли разбить на несколько переиспользуемых ?
- да - разбиваем и кастомайзим
- нет - делаем специфический в подпапке
Сервисы представляют организованых набор утилит и оберток. К сервисам можно отнести api вызовы и специфическая обработка этих вызовов. Например, можно выделить все запросы к апи юзера в отдельный сервис и потом через 3 аргумент redux-thunk заинжектить этот сервис. Это упростит тестирование и миграцию компонента на другое апи, т.к actions будут завязаны на определенный интерфейс сервиса, а не напрямую на http апи вызов.
В сервисы очень удобно выделять валидацию инпутов. Или парсеры которые приводят данные к одному виду.
Папка store содержит в себе бизнес логику и логику связанную с моделью данных . Сдесь происходит настройка redux store, а в каждом из подмодулей описываются бизнес сущности или модуль по работе с данными. Т.е это может быть отдельный модуль который делает загрузку любых сущностей и хранит их в сторе в нормализированом виде и предоставляет селекторы для загрузки данных. Так же это может быть модуль обработчик ошибок, который знает как обрабатывать разные типы ошибок.
Подмодули Store - эти модули могут содеражать в себе actions/reducers/selectors/middleware Каждый из этих елементов не является обязательным для подмодуля. При увеличении размера файла actions (или других файлов подмодуля) можно изменить файл
actions.js -> actions/
index.js
someGroupOfActions.js
someAnotherGroupOfActions.js
т.е превратить в папку и организовать по том что эти actions делают. Этот же подход можно применить и к reducers/selectors/middlewares для подмодуля
- DI в react/redux и зачем он надо
- скейлинг проекта при разных подходах
- подходы при разработке ui kit