Ничем не лучше и не хуже. Просто даст своим минусы и свои плюсы. Например какую никакую структуру. Всё равно одним сервисом с subj не обойтись, придётся операторы свои писать, методы какие то общие ещё что то
просто я смотрел на ютубе как внедряют ngrx и чет мне стало страшно от того сколько килотонн кода надо писать
ngrx-component-store посмотрите. Вчера на общем собрании вроди утвердили к применению)
https://ngrx.io/guide/component-store/comparison ???
Глянь akita или ngxs
Вот развернутый ответ. https://medium.com/ngx/practical-use-rxjs-81aaab57045c
https://www.youtube.com/watch?v=sxN5hmb2hdU
это по началу так кажется, когда понимаешь всю суть - становится куда проще. Вы пишете, что двумя сервисами можно обойтись - неужели у вас всего два состояния надо хранить? Все состояния надо разделять на отдельные стейты или сервисы, в зависимости от того, что в итоге используется. Поэтому я написал про 2 стейт менеджера. ngrx для более крупных приложений, ngxs для любых подходит. Чтобы сохранить состояние - нужно всего 2 файла, со стейтом и с экшеном. Удобство - всегда одинаковая структура стейтов, вряд ли кто-то будет городить поверх стейтов своё кастомное хранилище. Есть плагин redux-devtools для браузера, можешь в девтулзах видеть весь свой стейт, что в нём хранится и когда что сеттилось. Я видел кастомные решения стейт менеджеров и практически все они приходят к тому же самому, что и библиотеки
"вместе с вами реализуем собственный Ngrx на RxJS" - если это, чтобы объяснить как все работает, тогда супер. В другом случае я не понимаю зачем
можно делать много сервисов
Можно, хочу чтобы поняли - я не призываю использовать стейт менеджеры, их использование зависит от приложения, его размеров и задач, которые оно решает. Если приложение планируется крупное, где будет много запросов, которые могут зависеть друг от друга, стоит понимать, что на сервисах будет сложнее поддерживать.
Масштаб не определяет, необходимость ngrx. Но стей , в каком либо виде, будет всегда. Имхо
Обсуждают сегодня