Перейти к основному содержимому

Миграция с v1

Зачем v2?​

Изначальная концепция feature-slices была заявлена еще в 2018 году.

С тех пор прошло много трансформаций методологии, но при этом сохранялись базовые принципы:

  • Использование стандартизированной структуры фронтенд-проектов
  • Разбиение приложения в первую очередь - согласно бизнес-логике
  • Использование изолированных фичей, для предотвращения неявных сайд-эффектов и циклических зависимостей
  • Использование Public API с запретом лезть "во внутренности" модуля

При этом, в прежней версии методологии все равно оставались слабые места, которые

  • Где-то приводили к бойлерплейту
  • Где-то к чрезмерному усложнению кодовой базы и неочевидным правилам между абстракциями
  • Где-то к неявным архитектурным решениям, что мешало поддержке проекта и онбордингу новых людей

Новая версия методологии (v2) призвана устранить эти недостатки, сохраняя при этом и имеющиеся достоинства подхода.

С 2018 года развивалась и другая подобная методология - feature-driven, о которой заявил впервые Oleg Isonen.

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

По итогу это повлияло даже на наименование методологии - "feature-sliced"

Почему имеет смысл мигрировать проект на v2?​

WIP: Текущая версия методологии находится на стадии разработки и некоторые детали могут измениться

🔍 Более прозрачная и простая архитектура​

Методология (v2) предлагает более интуитивно понятные и более распространенные среди разработчиков абстракции и способы разделения логики.

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

📦 Более гибкая и честная модульность​

Методология (v2) позволяет распределять логику более гибким способом:

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

🚀 Больше спецификации, планов, комьюнити​

На данный момент core-team ведет активную работу именно над последней (v2) версией методологии

А значит именно для нее:

  • будет больше описанных кейсов / проблем
  • будет больше гайдов по применению
  • будет больше реальных примеров
  • будет в целом больше документации для онбординга новых людей и изучения концепций методологии
  • будет развиваться в дальнейшем тулкит для соблюдения концепций и конвенций по архитектуре

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

В будущем же, при следующих мажорных обновлениях - у вас сохранится доступ и к текущей версии (v2) методологии, без рисков для ваших команд и проектов

Changelog​

BREAKING Layers​

Теперь методология предполагает явное выделение слоев на верхнем уровне

  • /app > /processes > /pages > /features > /entities > /shared
  • Т.е. не все теперь трактуется как фичи/страницы
  • Такой подход позволяет явно задать правила для слоев:

    • Чем выше расположен слой модуля - тем большим контекстом он располагает

      (иными словами - каждый модуль слоя - может импортировать только модули нижележащих слоев, но не выше)

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

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

BREAKING Shared​

Инфраструктурные абстракции /ui, /lib, /api, которые раньше лежали в src-корне проекта, теперь обособлены отдельной директорией /src/shared

  • shared/ui - Все так же общий uikit приложения (опционален)
    • При этом никто не запрещает использовать здесь Atomic Design как раньше
  • shared/lib - Набор вспомогательных библиотек для реализации логики
    • По-прежнему - без свалки хелперов
  • shared/api - Общий энтрипоинт для обращения к API
    • Может прописываться и локально в каждой фиче/странице - но не рекомендуется
  • Как и раньше - в shared не должно быть явной привязки к бизнес-логике
    • При необходимости - нужно выносить эту связь на уровень entities или еще выше

NEW Entities, Processes​

В v2 добавлены и другие новые абстракции, для устранения проблем усложнения логики и сильной связности.

  • /entities - слой бизнес-сущностей, содержащий в себе слайсы, относящиеся напрямую к бизнес-моделям или синтетическим сущностям, необходимым только на фронтенде
    • Примеры: user, i18n, order, blog
  • /processes - слой бизнес-процессов, пронизывающих приложение
    • Слой опционален, обычно рекомендуется использовать, когда логика разрастается и начинает размываться в нескольких страницах
    • Примеры: payment, auth, quick-tour

BREAKING Abstractions & Naming​

Теперь определены конкретные абстракции и четкие рекомендации для их нейминга

Layers​

Segments​

  • /ui — UI-сегмент 🔥
    • Прежние варианты: ui, components, view
  • /model — БЛ-сегмент 🔥
    • Прежние варианты: model, store, state, services, controller
  • /lib — сегмент вспомогательного кода
    • Прежние варианты: lib, libs, utils, helpers
  • /api — API-сегмент
    • Прежние варианты: api, service, requests, queries
  • /config — сегмент конфигурации приложения
    • Прежние варианты: config, env, get-env

REFINED Low coupling​

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

При этом по-прежнему рекомендуется максимально избегать случаев, где крайне трудно "расцепить" модули

См. также​