feature-sliced

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

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

Overview

feature-sliced - структурная методология для JavaScript фронтенд проектов

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

См. также separation of concerns

TODO: будет дополняться позже

Структура

Пока что пришли примерно к такому варианту

Но т.к. все еще ведутся жаркие дискуссии - вариант неокончательный, хоть и составлен путем объединения разных опытов

└── src/
    ├── app/          # Инициализирующая логика приложения
    ├── processes/    # Процессы приложения, протекающие "над страницами"
    ├── pages/        # Страницы приложения
    ├── features/     # Ключевой функционал приложения (разбитый по фичам)
    ├── entities/     # Сущности
    ├── shared/       # Переиспользуемые модули
    └── index.tsx/    # Энтрипоинт приложения

/app/

└── app/
├── store/                      # Инициализация store
├── styles/                     # Инициализация styles
├── hocs/                       # Инициализирующая логика (HOC-обертки)
├── {...}                       #

/processes/

TODO: Позже будет дополнено

└── processes/

/pages/

└── pages/
├── {page}/                 # Ресурсы страницы (с минимальной логикой)
└── index.tsx               # Энтрипоинт (чаще всего с composed роутингом)

/features/

└── features/                          # Фичи приложения
  └── feature-name/                  #   Обычно содержит в себе:
          ├── components/            #      UI-компоненты фичи
          ├── {store/}               #      *Store фичи
          ├── {models/}              #      *Модели фичи
          ├── {...}/                 #
          └── index.ts               # Энтрипоинт фичи (с ее публичным API)

/entities/

└── entities/               # Сущности
├── user/                 #   Обычно содержит в себе (по необходимости):
|    ├── components/      #     *Подкомпоненты
|    ├── lib/             #     *Библиотеки
|    ├── api/             #     *Мб Подзапросы
|    └── store/           #     *Зашаренный Стейт
├── {entity-1}            #
├── {entity-2}            #
└── {...}/                #

/shared/

└── shared/             # Переиспользуемые модули
 ├── ui/              #   *UIKit приложения
 ├── lib/             #   *Библиотеки приложения (вместо свалки хелперов)
 ├── api/             #   *API-инстансы/методы
 └── {...}            #

P.S. Это не "серебряная пуля"

Не так много примеров проектов, которые полностью следуют правилам и принципам методологии, с сохранением преимуществ

Это связано с тем, что принципы вырисовывают очень идеальную архитектуру в теории, но сложную в реализации

На данный момент ведется активная работа над тем, чтобы соединить опыт многих разработчиков и выразить его в единой методологии, помогающей в реализации методологии в проектах

См. также

• О методологии
• Об архитектуре
• Об истории методологии
• NEW: О мотивации создания методологии
• Дискуссии по методологии

  Здесь обсуждаются и разбираются рельные примеры применения, вопросы, проблемы, идеи методологии

  Все это в совокупности влияет на спецификацию, тулкит и в целом - на дальнейшее видение и развитие методологии Т.е. все, чего пока нет в спецификации/тулките - так или иначе обсуждается в github-discussions

• Как можно помочь?
  • ⭐ Оцените нас на GitHub, если у вас остались положительные впечатления

    Или если по-вашему этот проект должен развиваться дальше

  • 💫 Ознакомьтесь с нашим contributing гайдом

    Важно любое содействие - от фидбека до участия в самой разработке!