- api
- features
- lib
- pages
- processes
- shared
- ui

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

в features лежат маленькие бизнес кейсы без вьюхи, только логика.
blog-post-creation, user-registration
Страница может композироваться из фич и шаред модулей.

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

Все эти сущности нужны для упрощения восприятия и модификации проекта, но требуют времени на освоение.

Я думаю никому не хочется, чтобы всё приложение было опасным для изменений(при модификации может сломаться что угодно и заранее невозможно предсказать что именно).

Каждая такая секция раскладывает код по сложности изменений и по опасности.
Если отсортировать их по сложности изменения, то получится такой список, самый первый самый простой для изменений, последний наисложнейший:
1. ui, lib
2. shared
3. features
4. pages
5. processes

А если отсортировать по опасности изменений, то получится ровно обратный список.
Первыми будут процессы, потому что от них никто не зависит и модификация процесса может сломать только процесс. А вот модификация страниц может сломать процесс, но только его.
Но при этом при изменении ui или lib, стоит быть максимально осторожным, потому что они используются во всем проекте.

Собственно эти списки показывают какие усилия требуется сосредоточить в каждой части кода. Например, становится очевидно, что ui и lib должны быть максимально покрыты unit-тестами и документацией. А процессы и страницы должны быть покрыты e2e тестами, чтобы правильно выполнять сценарии бизнес-логики.

Также внезапно становится очевидно, как погружать новичков в архитектуру проекта и взаимосвязи: нужно выдавать задачи пытаясь идти по списку выше, от модификации и создания ui и lib, предлагая напороться на сложность их переиспользования, а дальше постепенно увеличивая бизнес-ценность переходя от shared к features и страницам с процессами, при этом разработчик будет знать как устроен проект снизу.

- api
- features
- lib
- pages
- processes
- shared
- ui

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

в features лежат маленькие бизнес кейсы без вьюхи, только логика.
blog-post-creation, user-registration
Страница может композироваться из фич и шаред модулей.

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

Все эти сущности нужны для упрощения восприятия и модификации проекта, но требуют времени на освоение.

Я думаю никому не хочется, чтобы всё приложение было опасным для изменений(при модификации может сломаться что угодно и заранее невозможно предсказать что именно).

Каждая такая секция раскладывает код по сложности изменений и по опасности.
Если отсортировать их по сложности изменения, то получится такой список, самый первый самый простой для изменений, последний наисложнейший:
1. ui, lib
2. shared
3. features
4. pages
5. processes

А если отсортировать по опасности изменений, то получится ровно обратный список.
Первыми будут процессы, потому что от них никто не зависит и модификация процесса может сломать только процесс. А вот модификация страниц может сломать процесс, но только его.
Но при этом при изменении ui или lib, стоит быть максимально осторожным, потому что они используются во всем проекте.

Собственно эти списки показывают какие усилия требуется сосредоточить в каждой части кода. Например, становится очевидно, что ui и lib должны быть максимально покрыты unit-тестами и документацией. А процессы и страницы должны быть покрыты e2e тестами, чтобы правильно выполнять сценарии бизнес-логики.

Также внезапно становится очевидно, как погружать новичков в архитектуру проекта и взаимосвязи: нужно выдавать задачи пытаясь идти по списку выше, от модификации и создания ui и lib, предлагая напороться на сложность их переиспользования, а дальше постепенно увеличивая бизнес-ценность переходя от shared к features и страницам с процессами, при этом разработчик будет знать как устроен проект снизу.

@sovasergey подскажи плиз, в другом чате спрашивал вроде, но так и не разобрался для себя: есть компонент Navigation который в одном экземпляре на странице, он привязан к нескольким стором с данными по которым строются доступные пользователю разделы меню и подразделы, сейчас это feature/navigation, это норм? Есть мысль сделать navigation тупым темплейтом и прямо в app через effector-reflect прикрутить к нему все необходимые данные, в таком варианте этот template где должен располагаться? В ui?

я бы сделал shared/navigation
и экспортнул оба варианта, и привязанный и тупой.

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

Спасибо, но с shared / features еще больше запутался, в shared реюзабельные в приложении вещи находятся? Почему тогда в shared/navigation - она же в одном экземпляре?

Спасибо, но с shared / features еще больше запутался, в shared реюзабельные в приложении вещи находятся? Почему тогда в shared/navigation - она же в одном экземпляре?

Спасибо, но с shared / features еще больше запутался, в shared реюзабельные в приложении вещи находятся? Почему тогда в shared/navigation - она же в одном экземпляре?

Пробовал эти ограничения линтером кто-то чекать?

@unordinarity  Великий, не могли бы помочь?

Я бы сделал общие формы-организмы вроде form-payment и form-cashout, которые рисовали бы лежащие рядом частные организмы form-payment-type-foo или form-cashout-type-bar

Да. Такое можно сделать

Лучший 😂 В папке form или payment это все будет лежать?

payment. Вряд ли бизнесовая фича может именоваться «form»