Отказаться от сущности module

[sk1e]

Деление по таким сущностям избыточно, потому что:

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

Предлагаю заменить modules одним модулем Application, где будет файл со всем роутингом приложения, файлом routes с константой опиисывающей все роуты приложения через buildRouteTree, и каталогом pages куда будут складываться все компоненты страниц с подключением фич.

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

[krashaen]

Я правильно понял, то есть все фичи будут агрегироваться в Application? Если так, то этот app будет же очень жирным, не?

[sk1e]

Я правильно понял, то есть все фичи будут агрегироваться в Application? Если так, то этот app будет же очень жирным, не?

все фичи будут агрегироваться в отдельных компонентах в каталоге components модуля Application. Для каждой страницы свой компонент. Они будут настолько же жирными насколько были в каталоге components сущности module

[krashaen]

все фичи будут агрегироваться в отдельных компонентах в каталоге components модуля Application. Для каждой страницы свой компонент. Они будут настолько же жирными насколько были в каталоге components сущности module

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

[in19farkt]

а в остальном мне кажется это будут те же модули

так и есть, просто это деление на модули выглядит немного излишне. И по сути Серёгино предложение приведет к тому, что нынешние индексы модулей (которые содержат массивы раутов модуля), схлопнутся в один компонент, который внутри раскидает все странички по раутам. Глобально ничего не изменится, просто минус одна абстракция.

[Znack]

Ну на самом деле про избыточность модулей довольно громкое заявление :) Чтобы принимать такое решение, надо точно понять, в чём помимо недостатков ещё и преимущества модулей, плюс чем мы эти преимущества заменим в случае нового подхода.

[sk1e]

преимущества модулей

не заметил таких

[Znack]

Тогда тем более рано принимать решение по этому вопросу :) Возможно, сначала стоит обсудить, какие все-таки преимущества видят другие, и какие недостатки всплывут, если module убрать.

[sk1e]

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

[Znack]

Если тут никто не отписался за модули значит никому они не нужны.

Преждевременные выводы :)

Ну у них единственная область отвественности - мешать понимать структуру роутов и усложнять жизнь.

Мне кажется, что категоричность суждений может мешать в объективности понимания ситуации. Как минимум чтобы объективность увеличить помогать спросить других участников команды о причинах, почему та или иная абстракции были введены :)

[in19farkt]

На самом деле в том виде в котором они сейчас, и как мы их используем, то действительно смысла в них особого нет. Сейчас модуль выглядит так:

interface IModule {
  getRoutes?(): ReactElement<RouteProps> | Array<ReactElement<RouteProps>>;
  getReduxEntry?(): IReduxEntry;
}

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

Я уже выше отписал, что единственное изменение, к которому приводит Серегино предложение, это то что мы будем рауты собирать в более привычном стиле в одном месте, а не раскидывать их по индексам модулей и непонятно где они будут как-то объединены внутри одного Switch.

[Znack]

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

[sk1e]

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

Обычный компонент будет точно таким же интеграционным механизмом. В чём разница по-твоему?

[Znack]

Обычный компонент будет точно таким же интеграционным механизмом.

Давай это подробней :)

[sk1e]

Обычный компонент будет точно таким же интеграционным механизмом.

Давай это подробней :)

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