Что такое feature slice дизайн и его архитектура
Что проверяют
Знаете ли вы Feature-Sliced Design как методологию с конкретными правилами, а не как общую идею «раскладывать код по фичам». Интервьюер хочет услышать про слои, направление импортов и публичный API. Следом спрашивают, куда вы положите, например, кнопку «добавить в корзину».
Как отвечать
FSD делит код по трём осям: слои, слайсы, сегменты. Слои сверху вниз:
app: инициализация, провайдеры, роутер, глобальные стили;pages: страницы целиком;widgets: крупные самостоятельные блоки, например шапка или лента;features: действия пользователя с бизнес-ценностью, например вход, добавление в корзину, фильтр;entities: бизнес-сущности вроде пользователя, товара, заказа с их моделью и отображением;shared: всё без привязки к бизнесу, UI-кит, клиент API, утилиты, конфиг.
Слой processes признан устаревшим. Внутри слоя код режется на слайсы по предметной области (entities/user, features/auth), внутри слайса на сегменты по назначению: ui, model, api, lib, config. У app и shared слайсов нет, только сегменты.
Три правила, на которых всё держится:
- импорт только вниз: модуль видит лишь слои ниже себя,
featuresзнает проentitiesиshared, но не проwidgets; - слайсы одного слоя изолированы:
features/cartне импортируетfeatures/auth, связь собирается слоем выше; - публичный API: наружу слайс отдаёт только экспорт из своего
index.ts, глубокие импорты во внутренности запрещены.
В версии 2.1 появился подход pages first: код живёт в странице, пока не понадобится второй раз. Правила проверяют линтером Steiger или ограничениями импортов в ESLint.
Где спотыкаются
Описывают папку features с компонентом и Redux-слайсом внутри. Это feature folders, более простой подход, а FSD отличает иерархия слоёв и запрет импортов вверх.
Путают слайс в FSD со слайсом Redux Toolkit. В FSD слайс это папка предметной области, а не кусок стора.
Раздувают shared бизнес-логикой, а features превращают в свалку. Если в shared появился компонент, который знает про пользователя, его место в entities.