Comments 5
От «редуктора» покоробило. Лучше было остаться с редюсером.
Правильный ответ: DELETE_ITEM_SUCCESS может обрабатываться как редуктором items, так и редуктором favoriteItems.Это тоже неправильный ответ. Ну или не лучший из правильных. Я реализую это как действия редюсера, который стоит в узле дерева выше этих двух. То есть у одного Action всегда только один редюсер, который его обрабатывает. А этот родительский редюсер в свою очередь вызывает соответствующие чистые функции создающие новое дочернее состояние для этого родителя. Родительский редюсер же интегрирует это в состояние. примерно так.
export function parentReducer(prev: State, action: IAction){
switch (action.type)
case Remove:
return {
...prev,
items: childFunctions.removeItem(prev.items, action.itemId),
favoriteItems: childFunctions.removeItem(prev.favoriteItems, action.itemId),
};
}
Воспользовался вашим советом по поводу редюсера. Не ахти какой перевод, да лучше не придумать.
А по поводу «DELETE_ITEM_SUCCESS» — хорошее замечание. Сам бы я тоже не стал делать 2 отдельных состояния. Но, знаете, в реальной разработке всякое бывает. Может быть автор был вынужден так реализовать.
В любом случае, для меня эта статья совсем о другом, в большей степени про подход использования сервисов с чистым RxJS взамен Ngrx/effects.
А по поводу «DELETE_ITEM_SUCCESS» — хорошее замечание. Сам бы я тоже не стал делать 2 отдельных состояния. Но, знаете, в реальной разработке всякое бывает. Может быть автор был вынужден так реализовать.
В любом случае, для меня эта статья совсем о другом, в большей степени про подход использования сервисов с чистым RxJS взамен Ngrx/effects.
В текущем рабочем проекте для написания большого монолитного frontend-приложения на Angular решили брать полный инструментарий ngrx (store, entity, effects), основное применение effects в проекте — асинхронные операции (запросы к бэкенду).
В результате любой модуль обрастает излишней сложностью, например, если есть задача отслеживания контекста, из которого был отправлен action — допустим, нам нужно сообщить пользователю, что данные были успешно загружены с бэкенда, но только если пользователь ушел со страницы, с которой был отправлен action.
По личным ощущениям, можно оставлять только store и entity модули ngrx библиотеки, и делать любые максимально гибкие и расширяемые UX сценарии.
В результате любой модуль обрастает излишней сложностью, например, если есть задача отслеживания контекста, из которого был отправлен action — допустим, нам нужно сообщить пользователю, что данные были успешно загружены с бэкенда, но только если пользователь ушел со страницы, с которой был отправлен action.
По личным ощущениям, можно оставлять только store и entity модули ngrx библиотеки, и делать любые максимально гибкие и расширяемые UX сценарии.
Я с вами по большей части согласен. Но а от effects совсем отказываться не стоит. Есть редкие задачи, когда удобно следить именно за потоком экшенов. По моему опыту большинство задач требует слежения за потоком изменений данных в state, тогда я применяю сервис с чистым RxJS.
Тем самым, если задача требует слежения за потоком экшенов — effects, за потоком данных в state — сервис с RxJS.
Тем самым, если задача требует слежения за потоком экшенов — effects, за потоком данных в state — сервис с RxJS.
Мне кажется проблема даже не в том что нельзя что-то получить из контекста, это всегда можно решить расширяя стейт, проблема в том, что писать сколько-нибудь сложную логику/бизнеслогику на rxjs это самоубийство, и даже если не убились с первого раза, то со второго точно получится.
Sign up to leave a comment.
Прекратите использовать Ngrx/effects для этого