Skip to content

Latest commit

 

History

History
157 lines (118 loc) · 8.53 KB

README.md

File metadata and controls

157 lines (118 loc) · 8.53 KB
Raw

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 гайдом

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