Отказаться от сущности 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 и рендериться на своих роутах . Точно такие же, которые в модуле сейчас определяются и которые фичи подключают.

[Znack]

Компоненты будут друг друга импортить? Будут ли компоненты, которые интегрируют другие компоненты, иметь какие-то особенности?

[sk1e]

Компоненты будут друг друга импортить?

Нет, также как компоненты разных модулей не импортят друг друга.

Будут ли компоненты, которые интегрируют другие компоненты, иметь какие-то особенности?

Не понял о каких компонентах речь. Есть вероятность что в компонентах из components могут понадобиться общие компоненты по разметке страниц или компоненты со связками фич. Тогда можно завести каталог shared на том же уровне. И это удобнее будет по сравнению с текущей архитектурой на модулях. Там неудобно шарить между модулями общие штуки. Их складывают в modules/shared, а это, во-первых, далеко от места использования, во-вторых, у этого каталога незвучная семантика, т.к. shared не является модулем.

[sk1e]

И ещё сам термин module неудачен. Модуль это более абстрактная структурная единица, которая справедлива для самых разных сущностей, включая фичи. Мы ещё привыкли, а вот для других это диковато звучит.

[Znack]

И ещё сам термин module неудачен

С этим согласен

[Znack]

Есть вероятность что в компонентах из components могут понадобиться общие компоненты по разметке страниц или компоненты со связками фич.

не, я про то, как ты будешь решать задачу, когда тебе один компонент понадобится в другом, но это явно бизнесовая фича, в shared её утаскивать не очень удачная идея. Кто будет импортить компонент, от которого зависят, и как это будет передавать в компонент, который зависит?

[in19farkt]

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

Двухуровневая архитектура остается, просто модуль будет один, а не пачка))

[sk1e]

не, я про то, как ты будешь решать задачу, когда тебе один компонент понадобится в другом, но это явно бизнесовая фича, в shared её утаскивать не очень удачная идея. Кто будет импортить компонент, от которого зависят, и как это будет передавать в компонент, который зависит?

Когда компонент одной фичи потребуется компоненте другой? Ты определяешь в app/components, например, каталог MainPageLayout, там будет лежать компонент для главной страницы. Ты импортируешь в нём все фичи для главной страницы и тут же, в контейнеры фич которые зависят от других фич прокидываешь все необходимые зависимости. MainPageLayout, как и все другие страницы приложения, будет рендериться в App.tsx. Всё точно также как с модулями, только без избыточного разделения

[krashaen]

Обычно в модуль мы выделяем отдельную страницу. Сейчас у нас у модуля может быть свой редакс. Например на акме у нас были страницы(что то типа лендоса), выделение для них отдельной фичи смысла не было, мы юзали редакс в самом модуле, при новом подходе, если в модуле нужен редакс, он так же будет в папке с компонентом или как?

[sk1e]

Обычно в модуль мы выделяем отдельную страницу. Сейчас у нас у модуля может быть свой редакс. Например на акме у нас были страницы(что то типа лендоса), выделение для них отдельной фичи смысла не было, мы юзали редакс в самом модуле, при новом подходе, если в модуле нужен редакс, он так же будет в папке с компонентом или как?

нет, вся работа с redux-стейтом должна будет вынесена в фичу.

Что значит не было смысла выносить? Смысл есть всегда: компонент страницы не должен отвечать за такое, он отвечает за расположение компонентов фич и связь между фичами на конкретной странице. Для этого ему не нужен редакс. Редакс в этих модулях усложняет архитектуру без пользы.

[kinda-neat]

Когда компонент одной фичи потребуется компоненте другой? Ты определяешь в app/components, например, каталог MainPageLayout, там будет лежать компонент для главной страницы.

мб лучше components прямо назвать pages? app/components -> app/pages

[sk1e]

мб лучше components прямо назвать pages? app/components -> app/pages

ага, тоже об этом подумал

[Znack]

Так фичи в итоге остаются? Или они переименуются и станут components? И получается, что вы планируете текущие фичи сделать как pages?

[sk1e]

Так фичи в итоге остаются? Или они переименуются и станут components? И получается, что вы планируете текущие фичи сделать как pages?

Фичи останутся конечно, и не переименуются. Это те компоненты, которые сейчас являются компонентами модулей будут называться pages

[in19farkt]

Да, всё остается так же, просто модуль будет один (app), он распределяет фичи по страницам (pages) и раскладывает страницы по раутам.

[Znack]

Ну по сути тогда нам надо решить один вопрос: мы за то, чтобы архитектура на верхнем уровне отражали деление по бизнес-логике (на что рассчитаны модули), либо по роутингу. Если у нас где-то вылезет довольно сложная бизнес-логика, то привязка к роутингу сыграет не очень приятную штуку. Мы захотим выделить явно несколько блоков в бизнес-части, каждый из которых будет либо объединять несколько роутов, либо какие-то части будут на одном роуте расположены, с новым подходом придётся тут пострадать. Хотя для простых и средних проектов действительно, это предложение облегчит жизнь.

[sk1e]

Ну по сути тогда нам надо решить один вопрос: мы за то, чтобы архитектура на верхнем уровне отражали деление по бизнес-логике (на что рассчитаны модули), либо по роутингу.

Каким образом эти модули по бизнес-логике делят? Они также на роутинг завязаны ведь

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

Не понял тебя. Что ты тут под блоками бизнес-части подразумеваешь? Фичи? Что значит объединять несколько роутов?

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

части чего?

[Znack]

Каким образом эти модули по бизнес-логике делят? Они также на роутинг завязаны ведь

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

Не понял тебя. Что ты тут под блоками бизнес-части подразумеваешь? Фичи? Что значит объединять несколько роутов?

Не, что-то более высокоуровневое, чем фичи, например, профиль юзера. Он в себе компоузит несколько фич, выставляет несколько раутов и позволяет управлять из одного модуля всем, что связано с профилем.

части чего?

Части разных кусков бизнеса, которые объединены на одном роуте

[sk1e]

Тогда я думаю, что тут плохо разделена ответственность в модулях и фичах, и модули тем более нужно выпилить.

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

С новым разделением за отображение на роутах будут отвечать компоненты из app/view/pages, за отображение группы фич выделенных по бизнес-логике, которые можно подключать в разные страницы - app/view/shared, а стейт будут иметь только фичи.

Страдать тут, наоборот, только с модулями приходится:

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

Новое разделение ни в чём не уступает, компоненты из app/view/shared также могут композировать фичи, выставлять роуты и подключаться на разных страницах

[Znack]

Давай только не app/view/shared, shared, utils и тд имена давайте использовать ну совсем по минимуму. Если будем выносить из app/view/pages общие куски, которые объединяют какую-то бизнес логику, то давайте специально для этого абстракцию тогда и придумаем.

[sk1e]

давайте специально для этого абстракцию тогда и придумаем

макрофичи >_<