Перейти на PRO

Что должно быть в features в контексте FSD

Тип вопроса: Архитектура Вероятность: 10% Категория: Frontend Разработчик

Ответ

В FSD (Feature-Sliced Design) features — это слой, содержащий бизнес-логику и UI конкретных фич приложения. Он включает:

  1. UI-компоненты, специфичные для фичи.
  2. Логику (хуки, сторы, API-вызовы).
  3. Типы и константы, относящиеся к фиче.
  4. Тесты (юнит, интеграционные).

Фичи должны быть изолированы и слабо связаны с другими слоями. Пример структуры:

features/
  auth/
    ui/LoginForm.tsx
    model/authSlice.ts
    api/authApi.ts
    lib/hooks/useAuth.ts

Важно: фичи не должны зависеть от других фич напрямую, а общение между ними — через shared или app слои.

Ответ 18+ 🔞

А, ну это ж про FSD, про features слой! Слушай, да тут всё просто, как три копейки, если не наебываться.

Представь, у тебя есть приложение. И в нём есть вот эти самые «фичи» — ну, конкретные штуки, которые пользователь делает: авторизация, корзина, лента новостей, профиль. Так вот, в FSD под features — это как раз слой, где вся эта бизнес-хуйня и живёт. Всё, что касается конкретной фичи, валится сюда. Не в shared пихать, не в entities — а прямо сюда, в свою отдельную квартиру, чтобы не мешать соседям.

Что внутри-то? Да всё, блядь, что нужно для жизни этой фичи:

  1. UI-компоненты, которые больше нигде не нужны. Ну, типа форма логина. Её же в корзину не поставишь, верно? Значит, она тут.
  2. Вся логика — хуки, сторы (например, слайс для авторизации), API-вызовы к бэку. Всё, что заставляет фичу шевелиться.
  3. Типы и константы, которые касаются только этой фичи. type AuthFormData — куда его ещё, как не сюда?
  4. И тесты, конечно. Юниты, интеграционные — чтобы проверить, не развалилась ли твоя фича после пары правок.

Структура обычно такая, прям шаблонная:

features/
  auth/                     <-- Вот тебе целая фича "авторизация", живи тут
    ui/LoginForm.tsx       <-- Компонент формы, его стили
    model/authSlice.ts     <-- Стор, слайс, логика состояния
    api/authApi.ts         <-- Запросы на бэк: "эй, сервер, пусти меня!"
    lib/hooks/useAuth.ts   <-- Кастомный хук, чтобы не повторяться

И главное правило, ёпта, которое нарушают все распиздяи: фичи не должны тупо зависеть друг от друга напрямую! Нельзя из фичи cart лезть в auth и импортировать оттуда что попало. Это приведёт к ебучему спагетти, где всё завязано на всём, и потом ни хуя не разобрать.

Как тогда общаться? Да через общие, нейтральные территории! Через слой shared (общие утилиты, UI-киты) или через app (глобальные провайдеры, роутинг). Как дипломаты, блядь, через посредников. Слабая связность — залог того, что ты не охуеешь, когда придётся одну фичу переписать, а остальные должны работать как ни в чём не бывало.

Короче, features — это как отдельные модули в твоём приложении, которые живут по принципу «не лезь ко мне, и я к тебе не полезу, а общаться будем через общих знакомых». Соблюдаешь — жить будешь долго и счастливо, а нет — ну, жди пиздеца при рефакторинге.

© ХакСобесов, 2026
support@hacksobesov.com