Стартовый скелет приложения

[VladimirShestakov]

Файловая структура проекта, отвечающая всеми полезными принципами программирования (SOLID, DRY, KISS, ...)
Базовые решения для организации модульности, взаимодействия модулей, динамической погрузки модулей и для их оптимального разделения на чанки (при сборке).

Пробуем убрать из текущей версии скелетона все конкретные компоненты, сервисы, утилиты. Можно оставить что-то в качестве примера или если модуль часто используется и не модифицируется под задачи проекта.

Предлагайте идеи, наработки, удачные решения.

На основе стартового скелета будем прорабатывать в отдельных ветках конкретные фичи, интеграции и примеры.

[VladimirShestakov]

Что сейчас имеем в скелетоне

├──/dist — сборки приложения после `npm run build` 
├──/src 
|  ├──/app  — страницы и разделы приложения, роутинг
|  |  ├──/home 
|  |  ├──/...
|  |  └── index.js — корневой контейнер App с роутингом
|  ├──/components — повторно используемые глупые компоненты
|  |  ├──/elements 
|  |  ├──/layouts
|  |  ├──/menus
|  |  └──/...
|  ├──/containers — повторно используемые фрагменты приложения — умные компоненты
|  |  ├──/article-list 
|  |  └──/...
|  ├──/services — сервисы приложения, такие как состояние, слой АПИ и прочие 
|  |  └──/...
|  ├──/utils — функции, созданные под проект, в том числе утилиты скелетона, хуки, стилизация
|  |  └──/...
|  ├── config.js — настройки проекта
|  ├── index.html — единственный шаблон с корневыми тегами документа 
|  ├── index.node.js — главный файл приложения для NodeJS при SSR
|  └── index.web.js — главный файл приложения для браузера
├── ...
├── package.json
└── webpack.config.js — опции сброки и дев режима

[freydev]

идея фич в том, что в случае с папкой app, которая повторяет роутинг обычно нет ничего кроме index.js и стилей, компоненты там не желательны, компоненты в app импортируют части из containers, как не объединяй компоненты в containers, с ростом приложения папка захламляется и так просто не понять, какой контейнер для чего используется и используется ли. А так, если какой то раздел решили удалить, например и он удален из роутинга, можно без проблем удалить все папку с фичей и ничего не сломается, заодно удалятся и ненужные сущности стора

[freydev]

Не было ли тенденции фичи создавать меньшего размера? Т.е. не вся страница является фичей, а её части это фичи. И компонентом страницы просто агрегировать нужные фичи.

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

получается что если на сайте условно 5 больших разделов, есть 5 фич и пакет с модалками, если нужно добраться до какой то формы раздела, ты интуитивно знаешь где ее искать

[VladimirShestakov]

Фича старается быть самодостаточной частью приложения. Её легко привязать к роуту и целый раздел/страница готова к работе. Удобно когда страницы никак не взаимосвязаны. Фичей может быть и "виджет" для использования на разных страницах или нет? Главное меню, которое почти на всех страницах, является фичей? Корзина покупательская, которая и в модалке и на отдельной странице и в виде плашки в шапке на всех страницах? Обратил внимание, что в фиче ещё и своя модель состояния определена. А слой апи не часть фичи? Глупый, но особенный компонент, не часть фичи? Для меня вопрос, может ли фича действительно быть самодостаточной. Как однозначно разделить ответственность фич. Много вопросов на задавал чтобы и самому подумать)

[VladimirShestakov]

Что если фичу рассматривать не строго как цельную страницу, а как набор готовых решений. Папка catalog, в ней контейнеры таблицы товаров, фильтра да ещё и разных вариантов, какие-то ещё контейнеры. И модель каталога определена под конкретную библиотеку состояния. Интеграция в приложении заключается не сколько в прописывании в роуте, сколько в создании нужной композиции (страницы/модалки/сайдбара..) из этих контейров. Потому что на одной странице можно применить контрейлеры от разных фич.

[freydev]

Фича старается быть самодостаточной частью приложения. Её легко привязать к роуту и целый раздел/страница готова к работе. Удобно когда страницы никак не взаимосвязаны. Фичей может быть и "виджет" для использования на разных страницах или нет? Главное меню, которое почти на всех страницах, является фичей? Корзина покупательская, которая и в модалке и на отдельной странице и в виде плашки в шапке на всех страницах? Обратил внимание, что в фиче ещё и своя модель состояния определена. А слой апи не часть фичи? Глупый, но особенный компонент, не часть фичи? Для меня вопрос, может ли фича действительно быть самодостаточной. Как однозначно разделить ответственность фич. Много вопросов на задавал чтобы и самому подумать)

ну в данном случае, корзина и все что с ней связано, лежало бы в packages со своей моделью, например сейчас в активном проекте с таком архитектурой в packages есть жирный компонент с кучей модулей который обслуживает сам себя и его можно импортировать на любую страницу, есть пакет keycloak, который представлен моделью и методами авторизации и пакет dictionary - модель у которой можно запросить всякие перечисляемые списки, типы по полями, константы и тд. Api тоже часть фичи, это пример модели на mobx

import { SnapshotOut, types } from 'mobx-state-tree';
import { MomentPrimitive } from '@store/customTypes';
import { BaseAPIModel, modelToList } from '@store/base';
import { ListWithFilters } from '@store/listWithFilters';
import { Single } from '@store/single';
import { TEMPLATE_STATUS } from '@constants';

export const TemplateElement = types.model({
  id: types.identifierNumber,
  createTimestamp: MomentPrimitive,
  name: types.string,
  productCode: types.string,
  status: types.enumeration(Object.values(TEMPLATE_STATUS)),
});

export const TemplateElementSingle = types.model({
  createTimestamp: MomentPrimitive,
  name: types.string,
  id: types.maybe(types.number),
  content: types.string,
  productCode: types.string,
  status: types.enumeration(Object.values(TEMPLATE_STATUS)),
})

const TemplateModelSingle = types.model({
  data: types.maybe(TemplateElementSingle),
})

export const initials = {
  templateList: { url: '/template/_search' },
  templateSingle: { url: '/template/:id' }
}

const TemplatesModel = types.compose(
  BaseAPIModel,
  types.model({
    templateList: types.compose(ListWithFilters, modelToList(TemplateElement)),
    templateSingle: types.compose(Single, TemplateModelSingle)
  })
)

export default TemplatesModel
export type ITemplateElement = SnapshotOut<typeof TemplateElement>;
export type ITemplateElementSingle = SnapshotOut<typeof TemplateElementSingle>;

есть несколько базовых моделей(тут они называются ListWithFilters и Single), которые по разному обрабатывают url,  сами делают запросы, добавляют пагинацию и все прочее, в папке api/ у нас сейчас лежат мутации, можно было бы расширить сингловую модель, чтобы она могла еще и мутировать, но тогда не было времени