Приложение разрабатывается 100500 лет, там кода на миллион строк, если не больше, наверное)

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

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

@perkthefox Надо чейнить async логику из разных источников. В NgRx есть такая штука как Effects, которая позволяет изменять/добавлять/передвигать логику в async коде.

Например есть actions: LOAD_USERS, LOAD_USERS_SUCCESS, LOAD_USERS_FAIL
когда клиент вызывает LOAD_USERS - отправляется запрос на получения юзеров. При удаче он автоматически имитит ...SUCCESS (с полученными юзерами) и ...FAIL при ошибке.

Все просто, но допустим мне теперь надо каждый раз когда прилетает  LOAD_USERS_SUCCESS мне нужно имитить LOAD_USER_LOCATIONS, и при получении LOAD_USER_LOCATIONS_SUCCESS я должен сохранить только те локации которые юзер указал у себя в настройках как "Важные" (important).

Но в то время пока LOAD_USER_LOCATIONS запрос обрабатывается (до получения данных через LOAD_USER_LOCATIONS_SUCCESS) мне надо имитить другие операции...

Кейс так себе, но может показать наколько сложно-зависимые request/action pipes могут быть при разработке.

И это только я описал benefits of using @ngrx/Effects.
Один из самых больших плюсов в ngrx - это селекторы, которые помогают тебе вытаскивать из storage только те данные которые тебе действительно нужны

@perkthefox , и представь что где-то в такой системе зависимостей произошла ошибка?
NgRx прекрасно поможет тебе пошагово это продебажить и точно отследить место ошибки

Sounds legit

Типа этого: “How to use @ngrx/effects with simple http call?”...

Это то понятно, но он не видел смысла использовать ngrx так-как мог просто пользоваться root injected Services. И верить в их Singleton надежность.
И в 90% случаев это так, но в сложный кейсах - ngrx упрощает жизнь

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

но есть минус, нужно хорошо rxjs понимать, что для middle-разрабов в 95% случаев - проблема )

я ngrx как пример взял, конечно можно и другие state managers юзать) акиту не пробовал, сейчас гляну

А зачем нужен большой стор, в котором селекторами надо что-то вытаскивать?

ну мне вообще сложно читать angular код тех кто плохо понимает rxjs, даже без state manager

Звучит так, будто решаем героически проблему, которую сами себе создали

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

о да

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

мы просто реализуем бизнес логику)

Ага, поэтому пусть каждый компонент и работает со своим собственным стейтом

not always the case