Комментарии 13
Пост ни о чем, таких советов весь интернет.
НЛО прилетело и опубликовало эту надпись здесь
В последнее время всё чаще прихожу к мысли о ненужности и даже вредности каталогов типа components или services, особенно на первом уровне исходников. Идея о том, что на первом уровне располагаются каталоги с именами соответствующими основным элементам системы с точки зрения пользователя и/или бизнес-процессов, например, страницам-скринам, нравится всё больше. Ну и какая-то shared/common/lib для нужного всем. Единственная сложность: есть сущность Product и есть компонент, являющийся основным её представлением. В разметке хотелось бы видеть тоже <User /> но непонятно как их разделять.
Наболевшая тема.
На текущий момент пришел к структуре:
/components — базовые компоненты (кнопки, поля ввода, и т.д.) с запретом импорта других частей приложения
/data — функции общения с бекендом для абстрагирования
/dataComponents — компоненты с данными полученными с бекенда (CountrySelect например)
/forms — обернутые компоненты в redux-form Field, для более DRY форм
/layouts — компоненты без логики определяющие позиционирование компонент внутри себя и адаптацию под разные размеры экрана
/pages — компоненты на которые ссылаются роуты, не содержат в себе логики кроме передачи параметров роута (для абстрагирования от роутинга) и определения лэйаутов
/modules — независимые друг от друга части приложения с бизнес-логикой, как правило у каждого свой редюсер(ы)
В каждой папке свой eslint для запрета импорта некоторых сторонних библиотек или частей приложения и readme для справки
Получается следующая вложенность при реализации функционала:
Page-Layout-Module-Form-DataComponent-Component
Каждая компонента оформляется как
ComponentName/ — папка для группировки всего что относится к компоненте
— index.js — код компоненты
— ChildComponentName.js — код дочерней компоненты при декомпозиции
— ComponentName.test.js — юнит тесты компоненты
— stories.js — storybook для компоненты
— *.png/*.svg — всякие разные ресурсы компоненты
И я все еще не доволен результатом.
Разделение на папки важно, и чем их больше тем лучше проект документирует себя.
На текущий момент пришел к структуре:
/components — базовые компоненты (кнопки, поля ввода, и т.д.) с запретом импорта других частей приложения
/data — функции общения с бекендом для абстрагирования
/dataComponents — компоненты с данными полученными с бекенда (CountrySelect например)
/forms — обернутые компоненты в redux-form Field, для более DRY форм
/layouts — компоненты без логики определяющие позиционирование компонент внутри себя и адаптацию под разные размеры экрана
/pages — компоненты на которые ссылаются роуты, не содержат в себе логики кроме передачи параметров роута (для абстрагирования от роутинга) и определения лэйаутов
/modules — независимые друг от друга части приложения с бизнес-логикой, как правило у каждого свой редюсер(ы)
В каждой папке свой eslint для запрета импорта некоторых сторонних библиотек или частей приложения и readme для справки
Получается следующая вложенность при реализации функционала:
Page-Layout-Module-Form-DataComponent-Component
Каждая компонента оформляется как
ComponentName/ — папка для группировки всего что относится к компоненте
— index.js — код компоненты
— ChildComponentName.js — код дочерней компоненты при декомпозиции
— ComponentName.test.js — юнит тесты компоненты
— stories.js — storybook для компоненты
— *.png/*.svg — всякие разные ресурсы компоненты
И я все еще не доволен результатом.
Разделение на папки важно, и чем их больше тем лучше проект документирует себя.
Появляется новое поле или изменяется существующее в какой-то сущности, которое нужно показать/изменять на фронте и ві делаете изменения в, навскидку:
- data
- dataComponents
- forms
- modules
Вы не поняли назначение каталогов.
Все компоненты в components — это реализация дизайн системы проекта.
Допустим дизайнер передумал и решил что селекты в проекте должны быть кругленькими — изменение на уровне components.
Если нужно добавить новое поле в модуль, а подходящая компонента еще не разработана — создается новая компонента в components, делается обертка этой компоненты в forms и эта обертка используется в modules.
Все компоненты в components — это реализация дизайн системы проекта.
Допустим дизайнер передумал и решил что селекты в проекте должны быть кругленькими — изменение на уровне components.
Если нужно добавить новое поле в модуль, а подходящая компонента еще не разработана — создается новая компонента в components, делается обертка этой компоненты в forms и эта обертка используется в modules.
Как раз components в моём примере нет. Примерно так при добавлении поля никнейм в User
- data — добавление этого поля в десериализатор обработки ответа на GET /user/:id
- dataComponents — компоненты для вывода и редактирования никнейма как минимум
- forms — изменение формі создания/редактировани юзера
- modules — собственно добавление поля в модель User
Я немного запутался. Вы описываете свою структуру приложения или мою? Все что вы сейчас описали — не соответствует моей структуре.
Вашу. Как не соотвествует?
- /data — функции общения с бекендом для абстрагирования.
Куда вы положите функцию десериализации нового поля nickname. Не сюда? Если не сюда, то что будете менять, когда формат ответа с сервера изменится с, например, xml на json? - /dataComponents — компоненты с данными полученными с бекенда (CountrySelect например)
Не сюда вы положите NicknameView и NicknameInput? - /forms — обернутые компоненты в redux-form Field, для более DRY форм
Не здесь вы добавите NicknameField? - /modules — независимые друг от друга части приложения с бизнес-логикой, как правило у каждого свой редюсер(ы)
Не здесь буде т лежать какая UserForm, в котрую добавить NicknameField надо?
Я еще далеко не так хорошо прошарен в реакте как хотелось бы и во всех материалах, что я штрудировал, я нигде не встречал «storybook для компоненты». Не могли бы вы пояснить что это и для чего оно каждому компоненту?
Это не только про реакт.
Есть такой подход к разработке CDD (Component Driven Development), он подразумевает, что вы сперва пишите независимую от функционала компоненту, как правило в изоляции от приложения и от реальных данных, этакий example. И только потом уже собираете из таких компонент проект.
Storybook — это библиотека позволяющая вести разработку компонент в изоляции, составлять каталоги компонент, показывать различные примеры использования каждой компоненты.
В контексте моего комментария, storybook — файл с примерами использования компоненты.
Далеко не все его используют, да и с ростом популярности bit, storybook можно и не рассматривать как необходимость.
Есть такой подход к разработке CDD (Component Driven Development), он подразумевает, что вы сперва пишите независимую от функционала компоненту, как правило в изоляции от приложения и от реальных данных, этакий example. И только потом уже собираете из таких компонент проект.
Storybook — это библиотека позволяющая вести разработку компонент в изоляции, составлять каталоги компонент, показывать различные примеры использования каждой компоненты.
В контексте моего комментария, storybook — файл с примерами использования компоненты.
Далеко не все его используют, да и с ростом популярности bit, storybook можно и не рассматривать как необходимость.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Структурирование React-приложений