react-redux-starter-kit
react-redux-starter-kit copied to clipboard
fullstack-development
Отказаться от сущности module
Деление по таким сущностям избыточно, потому что:
- нам, и людям работающим с нашей архитектурой неудобно ходить по этим сущностям чтобы понять структуру роутинга и отыскать место где всё подключается;
- redux-слой модулей избыточен, т.к. его всегда можно вывести в фичу;
- усложняет инициализацию проекта.
Предлагаю заменить modules одним модулем Application, где будет файл со всем роутингом приложения, файлом routes с константой опиисывающей все роуты приложения через buildRouteTree, и каталогом pages куда будут складываться все компоненты страниц с подключением фич.
Роутинг не имеет смысла разбивать, т.к. его структуру и права доступа, которые с ним связаны, гораздо удобнее обозревать целиком, он не используется повторно и нормально масштабируется одним файлом учитывая потенциальное количество роутов приложения.
Я правильно понял, то есть все фичи будут агрегироваться в Application? Если так, то этот app будет же очень жирным, не?
Я правильно понял, то есть все фичи будут агрегироваться в
Application? Если так, то этот app будет же очень жирным, не?
все фичи будут агрегироваться в отдельных компонентах в каталоге components модуля Application. Для каждой страницы свой компонент. Они будут настолько же жирными насколько были в каталоге components сущности module
все фичи будут агрегироваться в отдельных компонентах в каталоге components модуля Application. Для каждой страницы свой компонент. Они будут настолько же жирными насколько были в каталоге components сущности module
ммм но тут не знаю насколько это круто будет, по сути тут я вижу плюс в том, что рауты в одном месте, а в остальном мне кажется это будут те же модули. Может я заблуждаюсь. интересно еще мнения почитать)
а в остальном мне кажется это будут те же модули
так и есть, просто это деление на модули выглядит немного излишне. И по сути Серёгино предложение приведет к тому, что нынешние индексы модулей (которые содержат массивы раутов модуля), схлопнутся в один компонент, который внутри раскидает все странички по раутам. Глобально ничего не изменится, просто минус одна абстракция.
Ну на самом деле про избыточность модулей довольно громкое заявление :) Чтобы принимать такое решение, надо точно понять, в чём помимо недостатков ещё и преимущества модулей, плюс чем мы эти преимущества заменим в случае нового подхода.
Тогда тем более рано принимать решение по этому вопросу :) Возможно, сначала стоит обсудить, какие все-таки преимущества видят другие, и какие недостатки всплывут, если module убрать.
Ну у них единственная область отвественности - мешать понимать структуру роутов и усложнять жизнь. Если тут никто не отписался за модули значит никому они не нужны.
Если тут никто не отписался за модули значит никому они не нужны.
Преждевременные выводы :)
Ну у них единственная область отвественности - мешать понимать структуру роутов и усложнять жизнь.
Мне кажется, что категоричность суждений может мешать в объективности понимания ситуации. Как минимум чтобы объективность увеличить помогать спросить других участников команды о причинах, почему та или иная абстракции были введены :)
На самом деле в том виде в котором они сейчас, и как мы их используем, то действительно смысла в них особого нет. Сейчас модуль выглядит так:
interface IModule {
getRoutes?(): ReactElement<RouteProps> | Array<ReactElement<RouteProps>>;
getReduxEntry?(): IReduxEntry;
}
т.е. тут реально тупо раут и всё. Причем с таким подходом мы не можем например динамически по какому-то флагу взять и вырубить раут, придется костылять (писать какие-то обертки), т.к. рауты модулей собираются в кучку на старте приложения, там где core логика запуска нашего приложения, в которую желательно лишний раз не лезть.
Я уже выше отписал, что единственное изменение, к которому приводит Серегино предложение, это то что мы будем рауты собирать в более привычном стиле в одном месте, а не раскидывать их по индексам модулей и непонятно где они будут как-то объединены внутри одного Switch.
Ну возможно тогда в текущих примерах использования модулей именно проблема, а не в самой концепции двухуровневой архитектуры. Фичи — самодостаточные и абстрагированные реализации бизнес-требований. Модуль — интеграционный механизм, который позволяет держать фичи чистыми от технических нюансов интеграции с другими фичами, к тому же соблюдая инверсию зависимостей.
Ну возможно тогда в текущих примерах использования модулей именно проблема, а не в самой концепции двухуровневой архитектуры. Фичи — самодостаточные и абстрагированные реализации бизнес-требований. Модуль — интеграционный механизм, который позволяет держать фичи чистыми от технических нюансов интеграции с другими фичами, к тому же соблюдая инверсию зависимостей.
Обычный компонент будет точно таким же интеграционным механизмом. В чём разница по-твоему?
Обычный компонент будет точно таким же интеграционным механизмом.
Давай это подробней :)
Обычный компонент будет точно таким же интеграционным механизмом.
Давай это подробней :)
ну ты в модуле App будешь держать файл App.tsx, который будет отвечать за весь роутинг и каталогом components, где будут компоненты с вот этим вот интеграционным механизмом и которые будут импортироваться в App.tsx и рендериться на своих роутах . Точно такие же, которые в модуле сейчас определяются и которые фичи подключают.
Компоненты будут друг друга импортить? Будут ли компоненты, которые интегрируют другие компоненты, иметь какие-то особенности?
Компоненты будут друг друга импортить?
Нет, также как компоненты разных модулей не импортят друг друга.
Будут ли компоненты, которые интегрируют другие компоненты, иметь какие-то особенности?
Не понял о каких компонентах речь. Есть вероятность что в компонентах из components могут понадобиться общие компоненты по разметке страниц или компоненты со связками фич. Тогда можно завести каталог shared на том же уровне. И это удобнее будет по сравнению с текущей архитектурой на модулях. Там неудобно шарить между модулями общие штуки. Их складывают в modules/shared, а это, во-первых, далеко от места использования, во-вторых, у этого каталога незвучная семантика, т.к. shared не является модулем.
И ещё сам термин module неудачен. Модуль это более абстрактная структурная единица, которая справедлива для самых разных сущностей, включая фичи. Мы ещё привыкли, а вот для других это диковато звучит.
Есть вероятность что в компонентах из components могут понадобиться общие компоненты по разметке страниц или компоненты со связками фич.
не, я про то, как ты будешь решать задачу, когда тебе один компонент понадобится в другом, но это явно бизнесовая фича, в shared её утаскивать не очень удачная идея. Кто будет импортить компонент, от которого зависят, и как это будет передавать в компонент, который зависит?
Фичи — самодостаточные и абстрагированные реализации бизнес-требований. Модуль — интеграционный механизм, который позволяет держать фичи чистыми от технических нюансов интеграции с другими фичами, к тому же соблюдая инверсию зависимостей.
Двухуровневая архитектура остается, просто модуль будет один, а не пачка))
не, я про то, как ты будешь решать задачу, когда тебе один компонент понадобится в другом, но это явно бизнесовая фича, в shared её утаскивать не очень удачная идея. Кто будет импортить компонент, от которого зависят, и как это будет передавать в компонент, который зависит?
Когда компонент одной фичи потребуется компоненте другой? Ты определяешь в app/components, например, каталог MainPageLayout, там будет лежать компонент для главной страницы. Ты импортируешь в нём все фичи для главной страницы и тут же, в контейнеры фич которые зависят от других фич прокидываешь все необходимые зависимости. MainPageLayout, как и все другие страницы приложения, будет рендериться в App.tsx. Всё точно также как с модулями, только без избыточного разделения
Обычно в модуль мы выделяем отдельную страницу. Сейчас у нас у модуля может быть свой редакс. Например на акме у нас были страницы(что то типа лендоса), выделение для них отдельной фичи смысла не было, мы юзали редакс в самом модуле, при новом подходе, если в модуле нужен редакс, он так же будет в папке с компонентом или как?
Обычно в модуль мы выделяем отдельную страницу. Сейчас у нас у модуля может быть свой редакс. Например на акме у нас были страницы(что то типа лендоса), выделение для них отдельной фичи смысла не было, мы юзали редакс в самом модуле, при новом подходе, если в модуле нужен редакс, он так же будет в папке с компонентом или как?
нет, вся работа с redux-стейтом должна будет вынесена в фичу.
Что значит не было смысла выносить? Смысл есть всегда: компонент страницы не должен отвечать за такое, он отвечает за расположение компонентов фич и связь между фичами на конкретной странице. Для этого ему не нужен редакс. Редакс в этих модулях усложняет архитектуру без пользы.
Когда компонент одной фичи потребуется компоненте другой? Ты определяешь в app/components, например, каталог MainPageLayout, там будет лежать компонент для главной страницы.
мб лучше components прямо назвать pages? app/components -> app/pages
мб лучше components прямо назвать pages? app/components -> app/pages
ага, тоже об этом подумал
Так фичи в итоге остаются? Или они переименуются и станут components? И получается, что вы планируете текущие фичи сделать как pages?
Так фичи в итоге остаются? Или они переименуются и станут
components? И получается, что вы планируете текущие фичи сделать какpages?
Фичи останутся конечно, и не переименуются. Это те компоненты, которые сейчас являются компонентами модулей будут называться pages
Да, всё остается так же, просто модуль будет один (app), он распределяет фичи по страницам (pages) и раскладывает страницы по раутам.
Ну по сути тогда нам надо решить один вопрос: мы за то, чтобы архитектура на верхнем уровне отражали деление по бизнес-логике (на что рассчитаны модули), либо по роутингу. Если у нас где-то вылезет довольно сложная бизнес-логика, то привязка к роутингу сыграет не очень приятную штуку. Мы захотим выделить явно несколько блоков в бизнес-части, каждый из которых будет либо объединять несколько роутов, либо какие-то части будут на одном роуте расположены, с новым подходом придётся тут пострадать. Хотя для простых и средних проектов действительно, это предложение облегчит жизнь.
Ну по сути тогда нам надо решить один вопрос: мы за то, чтобы архитектура на верхнем уровне отражали деление по бизнес-логике (на что рассчитаны модули), либо по роутингу.
Каким образом эти модули по бизнес-логике делят? Они также на роутинг завязаны ведь
Мы захотим выделить явно несколько блоков в бизнес-части, каждый из которых будет либо объединять несколько роутов
Не понял тебя. Что ты тут под блоками бизнес-части подразумеваешь? Фичи? Что значит объединять несколько роутов?
либо какие-то части будут на одном роуте расположены, с новым подходом придётся тут пострадать.
части чего?