Что такое FSD: лучшая методология для фронтенда
Гибкий и легко дорабатываемый фронтенд — не миф. Просто для этого нужно знать лишь одну методологию: и это FSD.
Что такое FSD
FSD — с английского Feature-Sliced Design, что можно перевести как «архитектура, разделённая по функциональности». И речь не про визуал, который видим глазами, а про дизайн папок и организацию хранения кода.
Какую проблему решает FSD
Многие разработчики при проектировании фронтенда сталкиваются с одной проблемой — через год командной работы почти любой проект превращается в каловую массу. Тесты и линтеры не помогают, потому что проблема не в коде, а в компонентах, лишнем CSS и дублирующихся JS-скриптах.
Уже без специального разбора непонятно, какие CSS-классы где и при каких обстоятельствах используются. Зачем нам 3 почти одинаковых JS-скрипта для работы с датами. А также неясно, какие компоненты можно безопасно вырезать и не развалить полпроекта, потому что они используются в 20 разных местах и умудряются переиспользовать себя.
Всё это приводит в одну точку: изменения одного участка начинают затрагивать весь проект, и даже нейросеть начинает вести себя не как помощник, а как враг, поедающий бесконечное количество токенов и генерирующий баги.
Что предлагает FSD
Данная методология предлагает организовывать хранение компонентов и кода по специальной иерархии. Посмотрите на скриншот ниже:
Когда смотришь на это в первый раз, ничего не понятно. Но давайте по порядку.
Слои (layers), слайсы (slices) и сегменты (segments) — всё это образует вложенную иерархию с простой идеей: слои состоят из слайсов, а слайсы — из сегментов.
Тут есть два основных правила.
Правило первое — если слой «выше», он может использовать слой «ниже». Слой pages может использовать всё от widgets и до shared, widgets — только features, entities и shared, ну а entities — только shared.
Грубо говоря, когда мы создаём страницу (слой pages), мы её собираем из всех слоёв: из widgets, features, entities и так далее. А если создаём что-то в features, то в нашем арсенале только entities и shared.
Правило два — назначение слоёв.
App — всё, благодаря чему приложение запускается: конфиги, роутинг, точки входа, глобальные стили и т. д.
Pages (страницы) — собранные из других слоёв компоненты.
Widgets (виджеты) — большие самодостаточные куски функциональности или интерфейса, могут реализовать целый пользовательский сценарий. Например: шапка, подвал, сквозные модальные окна.
Features (фичи) — код, который переиспользуется и относится к бизнес-логике. Например: кнопка добавления товара в корзину.
Entities (сущности) — базовые строительные блоки бизнес-логики приложения. Например: пользователь, товар, заказ.
Shared — переиспользуемый код, особенно когда он отделён от специфики проекта/бизнеса, хотя это не обязательно. Пример: функция приведения даты в строку.
Слои, слайсы и сегменты
Теперь детально рассмотрим каждый элемент FSD.
Слои
У нас есть слои: app, pages, widgets, features, entities, shared.
Каждый из них может состоять из слайсов. У слайсов может быть любое название. Это разделение на «сущности», иными словами. Дробление по предметной области.
Слайсы
Посмотрите на картинку ниже: слой pages, тут есть слайсы: home, settings и article-reader. Выше мы сказали, что они могут иметь любое название.
Всё, что связано с главной страницей — слайс home, настройками — settings. Далее уже эти страницы будут собираться из слоёв из низа иерархии, но сборка происходить будет в сегментах (подробнее в «Сегменты»).
Давайте пример: мы создаём слайс home, и внутри можно создать несколько сегментов: ui, model, api. Пока кратко: UI для HTML, остальное для JS.
Слайсы не могут брать содержимое других слайсов. То есть слайс home использует свои сегменты. Но не может обращаться к сегментам в article-reader или settings. То есть, JS-код сегмента model из слайса home это только код для слайса home.
Ах да, слои App и Shared, в отличие от других слоёв, не имеют слайсов и состоят из сегментов напрямую. Просто потому, что конфигам и общим функциям это не надо. Нет смысла делить их на предметные области.
Сегменты
Они «собирают» слайс.
UI — это HTML, Vue, React-компонент с вёрсткой.
Если это UI-сегмент какого-то слайса в слое pages, он может состоять из:
Своего уникального HTML-кода. Ну или Vue, React.
Других UI-элементов из слоёв widgets, features, entities, shared.
Если это UI-сегмент слайса в слое features, то логика такая же: свой код или другие UI-элементы слоёв ниже — из entities, shared.
Как раз та самая иерархия из начала.
Model — это state или какой-то другой код, обеспечивающий работу нашего UI. В нашем UI есть counter (счётчик) чего-то либо? Окей, пусть лежит в model.
API — это запросы к API. Обратились к API, заполнили model, отрисовали в UI.
Вопрос-ответ
Что должно быть центральной точкой входа в компонент?
Или «какой сегмент слайса должен быть точкой входа».
Это может быть UI или model. Главное, придерживайтесь общей логики. Например, мы используем Vue, поэтому точка входа в компонент — это setup, вот этот setup мы помещаем в model. А он уже вызывает HTTP-запрос к API из сегмента API, наполняет state для UI.
Слайсы создают сегменты только для себя?
Да, все сегменты можно использовать только внутри своего слайса. Так создаётся изоляция. Слайс home использует только свои сегменты. Он не может взять UI из другого слайса. Но он может взять UI из слоя ниже.
Мне нужен компонент, который можно использовать в нескольких слайсах pages, как быть?
Вариант 1: создаёте shared-слой и выносите туда UI. Далее дёргаете его откуда угодно.
Просто если часто злоупотреблять shared, у Вас будет куча кода, который везде используется. Так можно, обычно с этого и начинают миграцию по FSD, но от этого надо отходить.
Вариант 2: надо внимательно оценить требование и, возможно, создать feature или widget.
Например, в ERP есть модуль комментариев, он нужен на всего 3–4 страницах. Создайте feature — comments, далее вызовите в нужных widgets или pages.
Почему в вопросе выше предложили feature, а не widget?
Потому что feature гибче, его можно использовать как в pages, так и в widget. Если какой-то слайс в pages будет большой, плюс заметите, что надо использовать кусок какого-то кода в нескольких слайсах, то создадите widget, перенесёте туда такой код, а потом ещё и feature внутрь добавите.
Можно ли добавлять свои слои и сегменты?
Слои — нет, а сегменты — да. Обычно используют сегменты: ui, model, api, lib, config. Их чаще всего хватает. Мы, например, в некоторых проектах добавляем mappers. Если они выходят большими и жирными и не помещаются в model.
Но если надо добавить новый слой, то с большой вероятностью Вы просто не поняли FSD и ушли в «бесконечное» дробление ради дробления.
Есть примеры FSD-проектов?
Да, вот 4 замечательных примера. Тут, кстати, есть даже игра Tiny Bunny.
Получается, надо проектировать от низа: от entities и до pages?
На самом деле нет. Используйте page-first подход. Самый жирный слой — pages. Обратите внимание на примеры, все делают именно так.
Если начинаете замечать, что какой-то код переиспользуется, то начинайте выносить его в слои ниже. Какие-то «абстрактные» и базовые вещи (а-ля скелетоны, общие бизнес-процессы) в entities. А какие-то сложные, но повторяемые процедуры в features.
Все еще сложно? Тогда page-first + shared. С редкими попытками выноса какого-то кода в widgets.
По своему опыту скажем — widgets используем редко, так как если код повторяется в рамках процесса: комментарии, заявка, корзина — это точно feature. Всякие header, footer можно добавлять в widget, сами шаблоны тоже... но в рамках Vue шаблоны (layouts) можно и к App отнести, так как это почти точка входа.
Есть готовый SKILL для Codex, DeepSeek Harness и Claude Code?
Да.
Подведем итог
FSD — дико гибкая штука, многие её трактуют по-своему, многие спорят о «фундаментальных» вещах, но это и хорошо, значит, методология жива. Начните с pages и shared и постепенно прочувствуете всю силу FSD.
Более подробно можно читать тут, а это статья для новичков, первого старта и разжёвывания базового материала.