Entities: CRUD, Repositories, ListItems

[azinit]

Про сущности репозитории/синглтоны, и базовое проектирование CRUD операций в контексте FSD

[azinit]

Надо наконец где-то зафиксировать порочные практики по ItemsList компонентам

https://t.me/feature_sliced/6459
https://t.me/feature_sliced/3833

[azinit]

@RinAkaia заходи я создАл

[azinit]

прост как раз недавно обсуждали подходы к организации сущностей и фичей

пример таких соображений, где сущности организуются с уклоном в сторону clean:

Для сущностей
Отвественность сущности - работа с данными в стейте и представление базовых методов бл

Базовые/простые методы бл выделяются своей "одношаговастью" (с) @KarinaJovian

т.е. входные данные -> результат

Пример сущности: 
entities/card -> отдает стейт списка карточек, текущей карточки, CRUD методы, отвечает за синк с бэком, апдейтом локального состояния, записью в IndexedDB и тд и тп

entities/cart -> отдает состояние текущей корзины (список продуктов в ней), отвечает за его сохрание в LS, дает набор методов для работы с локальным стейтом корзины (добавить итем, удалить, и тд), а также методы/сторы вида $totalSum и другие производные данные

Для фичей
Отвественность фичи - реализация пользовательских сценариев из множества действий и шагов

Пример такой фичи:
features/edit-card -> включает в себя всю логику редактирования карточки:
- берет стейт текущей карточки из сущности
- готовит драфт-стейт редактируемой карточки для работы с редактором
- в процессе редактирования реализует логику сохранения промежуточных результатов, undo/redo и прочее, что приходит в голову для такого процесса
- отвечает и за всякие штуки типа сохранить последний драфт в ls/IndexedDB, чтобы не потерять изменения, если пользователь решит резко обновить страничку или еще что
- отвечает и за конечный результат, но тем способом, что просто передает новый стейт карточки в метод сущности вида entities/card -> updateCard

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

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

https://t.me/feature_sliced/3101

[azinit]

Как пример для понимания что лежит в фичах, а что в сущностях:

=== entities/task/model#addItem 
Добавление новой таски во внутренний стор тасков

- Чисто "служебное" применение
- Не представляет конкретной бизнес-ценности / юзкейса
- Как основной метод объекта/репозитория, если бы мы его на бэке описывали

=== features/create-task
Создание новой таски, с синхронизацией на сервере, обработкой шагов юзкейса

- Про конкретную бизнес-ценность и юзкейс
- Может использовать "служебные" методы из нижележащих слоев (entities)

https://t.me/feature_sliced/3776