в ангуляре. вот это поворот да? )))
Ну это логично - по функциональному назначению
Типо на один ендпоинт?
да, и даже 1 тот же метод можем дергать из разных сервисов
архитектура такая. у нас модули и сторы максимально разнесены. в прилаге много урлов и там свой функционал. Стараемся вообще не юзать никакие общие сервисы и сторы. Если по другому урлу нужен какой-то список, который был на другой странице - запрашиваем заново и пишем во временный стор, который привязан к урлу. При переходе в другой раздел сторы уничтожаются из памяти. Поэтому есть “дублирование” в разных модулях одних и тех же вызовов и т.п. Практика показала, что такой подход в долгосроке работает лучше и легче код поддерживать. Ты точно знаешь, что изменения в одном модуле не заафектят другие разделы. Поэтому и от глобального стора отказались. На какие-то справочники и прочее начинает ссылаться слишком много компонентов и логики. И через полгода ты уже просто так ничего не поменяешь, не загрузив в голову всю логику всех разделов, которые связаны с глобальными данными. То есть поддержка становится очень дорогой. А тут вся логика разбита на вообще не связанные модули. Можно сказать почти микрофронтенды получаются, без каких-либо общих частей. Не навязываю этот подход, но в наших проектах это супер зашло и в принципе на митингах все согласились, что так лучше, хотя поначалу все были адептами DRY :).
+1 потому что DRY не про дублирование коа, а про дублирование логики если в двух местах нужны одни данные, то это совпаление может быть случайным
согласен абсолютно. просто его воспринимают буквально и не дай бог повторить какой-то кусок. 🙂
я с подобной проблемой встречался в сторе. Разрботчик две разные бизнес логики объединил в одном селекторе. В итоге изменения в одном смарт компоненте, эффектили другой т.к они оба были подписаны на этот селектор. Было очень сложно менять бизнес логику, чинишь в одном месте , ломается другое. В итоге я разнес единый селектор на несколько.
Обсуждают сегодня