[ARCHIVED] Применимость feature-sliced в бою

[azinit]

@sergeysova провел созвон с одним из приверженцев feature-sliced, который поделился опытом и поставил перед методологией весомые вопросы

[azinit]

Фичи бывают разные...

features

В некоторых проектах весь функционал сосредоточен в данных с сервера

Например, в схемах/конфигах в сервисах-конструкторах, библиотеках-генераторах логики в виде пакетов и т.д.

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

Так - понятие feature может в целом мало говорить про бизнес-ценность, и быть например - чем-то более абстрактным и очень переиспользуемым, в отличие от обычных случаев

Т.е. здесь feature больше похожа на какой-то абстрактный многошаговый процесс, который уже несет бизнес-ценность бизнесу

[azinit]

API и Бизнес-Логика

shared api

Бывает, что нужно привязать конкретную БЛ при работе с API (например уведомления пользователя)

Но т.к., по-хорошему, напрямую shared/api про подобную логику ничего знать не может, как и импортить более верхнии абстракции (features/entities), есть обычно два пути:

1. RECOMMENDED: Класть в app инициализацию логики работы с API

   Так ни entities, ни shared не будут знать про эту сложную логику - она будет явно наслаиватся сверху как middlewar-ная логика

2. Можно также явно завести entities/notifications, со своей моделью и эффектами

   @sergeysova для entities практикует отдельно держать ui (без подписки на стор) и отдельно модель, чтобы можно было изолированно использовать без циклических зависимостей

Обычно у нас один shared/api на все приложение (крайние случаи не рассматриваем пока)

И по методологии, он не может что-либо знать про саму бизнес-логику, и соответственно импортить определенные features/entities

[azinit]

LIB и стейт

shared lib

У shared/lib не может быть стейта, поскольку в таком случае - не получится на нее нормально полагаться, переиспользовать и тестировать

Если нужен стейт - импортим либу в entity/ feature и подтягиваем на этом уровне нужную модель данных (store)

[azinit]

UI, API и стейт

shared ui api

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

Так, связку компонента и API лучше организовывать на уровне entity/ feature

Лучше декомпозировать и держать логику максимально явно и просто, чтобы было легко потом изменять

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

shared/ui не может хранить стейт, т.к. компоненты должны быть легко переиспользуемыми

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

Поэтому, например, не нравится подход GraphQL: запросы лежат рядом, и каждый раз как меняют API - ломается половина кода, т.к. все распылено по проекту

Нет чего-то проксирующего, и поэтому ui стучится к реальному API

Стоит также понимать, что в shared/ui нет места и для инициализации - выносим такое на уровень app

[azinit]

Про роутинг и обработку ошибок

app pages

Есть разные страницы и возможны случаи:

1. Доступна для анонимных пользователей
2. Доступна только для авторизованных пользователей
3. Доступна для обоих типов, но меняет отображение в зависимости от isAuthenticated

Не всегда удобно резолвить роутинг на уровне pages (каждая страница точно не может этого делать), поэтому часто этим занимаются процессы

Обычно хранят такие вещи в entity/session (см. также principle, viewer)

Где хендлить ошибку 401?

Лучше обрабатывать на уровне app, но также порой и давать возможность перехватывать и обрабатывать только на page

[azinit]

Nav-меню и БЛ

nav

Привычный пример: есть меню с логикой навигации, и чтобы отрисовать нужно:

1. Знать информацию по сессии пользователя (isAuthenticated)
2. Знать доп. данные с API (например схему для сайтов-конструкторов)

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

По сессии - можно брать информацию из entities/session (иногда еще называют principle, viewer)

Сам процесс же - представлен в виде process, а конкретный способ авторизации - в виде feature (auth-by-phone)

[azinit]

Сами страницы могут оставаться такими, какими были просто мы вынесем общие компоненты(такие как header/nav-menu) в pages/ui / pages/components. В любом случае таких компонентов будет не очень много

По-своему опыту знаю, что оч быстро появится желание превратит этот pages/components в свалку - поэтому если можно избежать такого - лучше избежать)

Плюс путанница, т.к. некоторые вместо того чтобы оставлять логику в pages/**/ui будут хотет выносить в pages/ui "на будущее"

[azinit]

Сцепились с @ilyaagarkov

@ilyaagarkov
Не вижу смысла трактовать navigation как фичу, считаю что это должно быть shared для всех страниц и класть его в pages/ui

@martis-git
Хз, navigation несет же в себе бизнес-ценность определенную как фича
И логику в себе может содержать, плюс быть заимпорченной и конкретной страницей, так и сразу в app

@ilyaagarkov
но как быть что в том же хедере или сайдбере могут быть несколько фич? мы же не можем импоритвароть фичи в фичи

@martis-git
Было такое, обычно Sidebar был как обычный shared/ui и внутри него через children пропихивал нужные фичи

Тут обычно такие варианты (в зависимости от проекта):

1. app/navigation - если навигация простая и нужна на всех страницах, без особой логики (никто ниже не имеет доступ к компоненту)
2. shared/ui/navigation - навигация, как shared/ui, может использоваться как темплейт и юзаться и в pages и в features и в entities
3. features/navigation - навигация как полноценная фича, если нужно, чтобы там был определенный функционал, если же нужно пропускать определенные фичи внутрь (какую-нибудь кнопку например особенную), то резолвим на уровне страницы и пускаем через children (<Nav> <SomeFeat/> </Nav>)

@ilyaagarkov
А если таких страниц 10 или 50? И если нужно что-то менять? Поэтому по-моему nav не может быть фичой
Я бы еще согласился, если бы это был процессом, но импортить в таком случае мы не можем, поэтому лучше pages/ui

[azinit]

@ilyaagarkov навигация как процесс... ну хз хз

Есть вероятность, что можно разделить по entities, но чет сложно пока такой кейс представить

@sergeysova спаси ситуацию пож

[ilyaagarkov]

Я предлагаю обсудить этот пример на созвоне.

[ilyaagarkov]

что раз по нашей же методологии pages это абстракция верхнего уровня, а значит может в себе содержать свой набор ui/libs

тут да, я не прав ведь ui/libs по этим правилам могут быть лишь у каждой конкретной page, а не общие у всех. Тупанул

[azinit]

Что есть entity и feature?

entities

entity - обычно легко обосновать с точки зрения ООП

Условно "могу ли я сделать new Entity(...)"

Сущность - делает только в рамках одного инстанса , и делать ты можешь что-то только с этим инстансом

features - скорее как операции над сущностями

[azinit]

Переиспользуемая логика и features

shared features

При реализации фичи, есть желание юзать больше чистых функций, для каких-то базовых валидаций, редиректов - и засунуть такое сразу в shared/lib

Но тогда логика распыляется между shared и features

Как лучше поступить:

• рекомендуется в shared выносить только когда "используется не в одном месте"

• при прототипировании - писать все без особой декомпозиции (можно сразу в index-файле), а после уже - растряхивать по структуре

  Т.е. как только логика реализована и видно, что проблем нет - можно разделять по модулям, не отвлекаясь на лишнее

[azinit]

См. также #14

[azinit]

Cross-imports и анализ зависимостей

Никогда и нигде не рекомендуется практиковать cross-imports, иначе придется бороться с циклическими зависимостями

Н-р: фича импортит другую фичу

Чтобы резолвить такие ситуации - практикуется проектировать модули так, чтобы их было легко расширять

Например есть <Post/> и <Comments />. И чтобы явно не указывать зависимость - лучше добавить реализацию children, и через него расширять отображение и логику по-нужному

Для анализа и предотвращения можно использовать:

• eslint-plugin-boundaries
• dependency-cruiser
• madge

[azinit]

Что за сущности?

Есть строго упорядоченный список: app, processes, pages, features, entities, shared

По осведомленности и правам: сверху-вниз - самый осведомленный по БЛ - app, наименее осведомленный - shared

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

• Каждый знает и может импортировать всё и только всё что ниже его по уровню

  • app ⇒ processes, pages, features, entities, shared
  • processes ⇒ pages, features, entities, shared
  • page ⇒ features, entities, shared
  • feature ⇒ entities, shared
  • entity ⇒ shared
  • shared ⇒ ∅

По опасности внесения изменений: снизу-вверх - самый опасный - shared, наименее опасный - app

Если конкретно

• shared - переиспользуемая логика, оторванная от БЛ

• entity - сущность, для реализации отдельного аспекта БЛ

• feature - функционал (обычно действие), для реализации конкретной бизнес-ценности

• page - конкретная страница, с простой логикой и композицией фичей

• process - процесс, use-case для реализации многошаговой БЛ

  Может менеджить роутингом (хотя иногда достаточно и entity)

  Пример

  Оформление заказа

  • Этапы: подтверждение, доставка, оплата, и уведомление (и все это надо менеджить)
  • Кажется что должно быть на странице, но страницы не должны это знать
  • И когда появляются сложные случаи (где страницы используются по-разному, с комплексной логикой и разнообразием проверок) - лучше внедрять новую сущность - процесс
  • На конкретной странице - не будет логики редиректа в таком случае

• app - "точка входа" в приложение, с логикой инициализации

[ilyaagarkov]

Возник вопрос по процессам,
запустить какой либо процесс может только app, так как никто больше не может импортить ничего из процесса.

Какой тогда будет флоу, чтобы запускать какой-либо процесс(например многошаговой регистрации) из ui?

[azinit]

Какой тогда будет флоу, чтобы запускать какой-либо процесс(например многошаговой регистрации) из ui?

А зачем ui должен запускать процесс?

Я конечно прям процессы у себя так не реализовывал отдельно, но скорее всего это бы на уровне модели (store) инициализировалось

Наверное на уровне app вызывался бы какой-нибудь HOC, а внутри - диспатчилось событие в модель (store)

[ilyaagarkov]

Как вариант процесса всегда приводят многошаговыую регистрацию.
Вот и вопрос, как от нажатия кнопки "Sign Out" (где-нибудь в хедере) мы перейдем к запуску этого процесса?

Именно весь флоу и без нарушений границ

[azinit]

В Redux бы наверное стейт для процессов хранился все время приложения, но вовремя бы сбрасывался до нужного стейта

Но тут думаю @sergeysova с эффектором лучше объяснит думаю

[ilyaagarkov]

я прошу описать без привязки к STM, а с привязкой к feature-sliced

В Redux бы наверное стейт для процессов хранился все время приложения, но вовремя бы сбрасывался до нужного стейта

вопрос не "где хранить стейт", а как запустить процесс.
Возможно лучше тоже оставить на созвон.

[azinit]

Про общие типы

shared types

До этого была дискуссия - куда класть общеиспользуемые типы моделей

@sergeysova: Мало кто готов класть в корень, поэтому стараюсь класть в соответственное место, как и обычный код (в конкретный компонент/абстракцию и т.д.)

[azinit]

@sergeysova как мне кажется тут скорее имелось в виду не "про обычные типы", а про "типы со схемы моделей", которые обычно так или иначе задействуются в любой точке приложения"

type Post, type User, type Comment, type Cart, type CartItem, ...

[azinit]

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

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

[sergeysova]

Я бы предложил такие типы класть в Entities. Иначе соседние entities начинают знать друг о друге благодаря типам. Типы это такой же код, как жс.

[azinit]

Го сюда перейдем)
#51

[azinit]

Кнопка-фича

shared/ui features

Q: Вот есть кнопка загрузки/прогрузки/создания и т.д. - и это есть фича?

A: Сама кнопка - ui, но фича - только если получится представить это в виде бизнес-ценности (определенный результат и процесс)

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

Смысл фич - чтобы каждая фича делала что-то одно и была возможно переиспользуемой

[azinit]

Про тестирование

tests

Начнем с конца:

• shared - тестируется легко, units tests

• entities - посложнее, но можно (эффектором)

• features - т.к. полагаются на многое, юзаем integration tests

• pages - тоже можно покрыть unit tests (т.к. обычно там простая логика)

  Как понять что страница работает правильно?

  • На уровне модели:
    ⇒ Проверяем, что модель экспортит ожидаемые события при поступленных данных

    • Смотрим на store, и мокаем уже редьюсеры

  • На уровне вьюшки:
    ⇒ Стараемся чтобы вьюшка вообще не знала про модель, поэтому обычно создаются экшены отдельно и через контракт связываются (как штекер и розетка)

    • И потому можно пустить по данным туда - то что хочется и нужно

• /ui - покрываешь скриншотами

Про подход

Стараемся по семантичности - то как это видит пользователь

test-id/className использовать - к хорошему не приведет (были случаи, особенно при рефакторинге)

[azinit]

Вроде @sergeysova именно "скриншотами" говорил

По-разному же тестить можно)

Хотя тут уже близко к холивару

[vladdof]

а можно пояснение этой фразы test-id/className использовать - к хорошему не приведет (были случаи, особенно при рефакторинге), чтобы понимать к чему это может привести

[azinit]

Вот можно глянуть
https://testing-library.com/docs/react-testing-library/intro/

Если вкратце - data-test-id/className/id - это про РЕАЛИЗАЦИЮ компонентов внутри, которые постоянно меняются
Лучше брать более семантичные селекторы, как это видит пользователь (aria-label/role и т.п.)

[azinit]

Но это уже вопрос больше про подход к тестирование, чем про архитектуру и FSD

[azinit]

@vladdof