Угловой 2: Разница между сервисом и сокращением

Question

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

Answer 1

Служба представляет собой детали с угловым исполнением. В то время как redux является архитектурной концепцией. Эти два не сопоставимы напрямую.

Если вас интересует, как redux может применяться к угловому, я бы рекомендовал прочитать Comprehensive Introduction to @ngrx/store.

Answer 2

Вам не требуется редукция, но вам нужен способ поддержания состояния. Служба будет работать, но в конце вы отправите что-то похожее на магазин redux или ngrx.

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

И вы хотите настроить шаблон, который может использоваться в нескольких компонентах.

У Виктора Савкина есть способ сделать это с помощью наблюдаемых, которые очень гладкие. У Ngrx есть другой путь.

Я написал умеренно сложный компонент, используя службу. Все нормально. Часы исчезнут в отслеживании некоторых странных ситуаций, когда состояние было неопределенным и забросило ошибки. Я слишком сильно попадал в сорняки, чтобы иметь что-то многоразовое, как образец. И результат был хрупким и хрупким. Это не было полностью реактивным, и сделать это оказалось чрезвычайно сложным и трудоемким. Я портировал его на ngrx, и как только кривая обучения преодолена, что не является тривиальным, код стал проще и полностью инструментальным, позволяющим быстро отлаживать.

YMMV.

Victor Savkin has an article on how to maintain state