что-то усложняется подход, хочется описания спеки новой прямо

Все кто выше по абстракциям)

Выше это значит на том же уровне?

- app
- features
- pages
- processes
- models
- shared

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

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

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

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

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

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

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

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

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

Мы вот к этому и идём

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

А вообще тут в README тож базово изложено
https://github.com/feature-sliced/wiki

(но если хочется посмотреть и/или повлиять на текущий фронт размышлений - велком в discussions)

вики это круто, но вот определений не хватает для сущностей (или я пропустил?)

прямо вот хочется зайти и прочесть что есть feature, а что entity

В процессе)

Но @sovasergey выше в сообщении хорошо в принципе описал

Как раз сейчас и обсуждаем это все

Да я читаю:) я без нападок, просто вот со стороны если смотреть то первая версия fs была проще

Что такое зашареный стейт в энтитес?

Чем энтити вцелом от фичи отличается?

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

А раньше entities - это был shared, а UI/lib - наверху лежали

Нууу хз насколько проще)

Тут конечно и мы со своим видением пришли, суету навели

Но как никак мердж разных опытов

кто же спорит, но хочется определений, иначе без терминологии общей мы не сможем совсем общаться

У нас оно и очерчено но пока что в состоянии черновика)

Все будет на след стриме думаю, как и говорили

(Если оч интересно - то опять же - дискуссии, там легко найти нужный топик по твоему запросу)

Все будет)

Все будет

Хорошо

Но я думаю - это пока самое развернутое (или же на стриме последнем пример приводили)

👍