NGRX Effects — где/как организовать определения эффектов.

Я использую @ngrx/effects в приложении angular2 и борюсь с организацией различных определений эффектов.

У меня есть сущности Identity и Subscription, каждая со своими собственными службами действий IdentityActions, SubscriptionActions, а также своими службами эффектов IdentityEffects, SubscriptionEffects.

Определены следующие действия.

IdentityActions.AuthorizeIdentity()
IdentityActions.OnIdentityAuthorized(identity)
SubscriptionActions.GetSubscriptionList(identity)
SubscriptionACtions.OnSubscriptionsListed(subscriptions)

После авторизации удостоверения я сразу же хочу получить список его подписок. Как @ngrx/effects поддерживает организацию этих эффектов, чтобы их можно было отследить/легко найти позже (например, через год)?

В IdentityEffects:

@Effect()
this._actions.ofType(authActions.AUTHORIZE_IDENTITY))
  .switchMap(() => this.svc.AsyncAuth())
  .switchMap((identity) => authActions.OnIdentityAuthorized(identity))

@Effect()
this._actions.ofType(authActions.ON_IDENTITY_AUTHORIZED)
  .switchMap((identity) => Observable.of(action, subActions.GetSubscriptionList(identty))

Это кажется естественным при написании, потому что получение списка подписки является следствием авторизации личности... но меня это беспокоит, потому что, если разработчик когда-либо пытается отследить, откуда берется список подписки, это не так. Не интуитивно понятно копаться в IdentityService.

Альтернативой является регистрация второго эффекта в CustomerEffects, который не испускает..

@Effect({emit: false})
this._actoions.ofType(authActions.ON_IDENTITY_AUTHORIZED)
  .switchMap((identity) => Observable.of(action, subActions.GetSubscriptionList(identity))

Кажется, что это будет легче найти в долгосрочной перспективе... Но при написании это кажется менее естественным (я пишу побочный эффект идентификации в службе подписки...)

Что такое проверенный временем подход (если времени вообще достаточно)?


angular ngrx ngrx-effects
person josh-sachs    schedule 08.03.2017    source источник
comment
Вы видели их пример приложения?   -  person cgatian    schedule 09.03.2017
comment
Непонятно, что делают некоторые из этих фрагментов. Например, что такое action в последнем фрагменте? Действие, вызвавшее эффект? Если да, то зачем его переиздавать? Его бы уже передали редукторам. И если GetSubscriptionList обновляет какое-то состояние, используя какой-либо механизм, отличный от отправленного действия, то, что вы делаете, больше не является Redux.   -  person cartant    schedule 09.03.2017
comment
У меня сложилось впечатление, что имена моих служб были довольно стандартными. subActions — это класс, предоставляющий методы, которые генерируют действия, связанные с подписками на хранилище. Он также содержит константы для разрешения типа действия. Последний эффект отправляет два действия: одно перехваченное (чтобы удостоверение применялось к состоянию) и второе, которое генерирует действие GetSubscriptionList. Вопрос, я думаю, во всяком случае, довольно ясно. Как лучше всего зарегистрировать эффект, выходящий за рамки основного ресурса файла.   -  person josh-sachs    schedule 10.03.2017
comment
Я посмотрел пример приложения. Он настолько прост, что ни одна из их проблем даже не может пересечь границу, подобную этой. Когда кто-то входит в систему, побочным эффектом является получение списка его подписок. Я не могу найти четкого руководства о том, где рекомендуется регистрировать этот побочный эффект... как IdentityEffect или SubscriptioEffect.   -  person josh-sachs    schedule 10.03.2017

Ответы (1)


arrow_upward
1
arrow_downward

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

Я решил, что имеет смысл группировать эффекты по объекту, на который они воздействуют, а не по тому, что вызывает эффект.

В 95% случаев это приводит к тому, что определение службы эффектов относится ровно к одному объекту... однако в некоторых случаях может быть один или два эффекта, которые ссылаются на что-то другое.

В моем примере Identity аутентифицируется, что приводит к загрузке подписок.

IdentityEffectsService.ts

@Effect()
public AuthorizeIdentity$ = this._actions.ofType(AUTHORIZE_IDENTITY)
  .switchMap(() => this._identitySvc.Authorize())
  .map(identity => this._identityActions.OnIdentityAuthorized(identity))

@Effect()
Public OnIdentityAuthorized$ = this._actions.ofType(ON_IDENTITY_AUTHORIZED)
  .do(identity => console.log(`${identity.name}` logged in!`));

SubscriptionActionsService.ts

@Effect() ListSubscriptions$ = this._actions.ofType(LIST_SUBSCRIPTIONS)
  .map(action => <Identity>action.payload)
  .switchMap(identity=> this._subscriptionSvc.List(identity))
  .map((subs) => this._subscriptionActions.OnSubscriptionsListed(subs))

@Effect() OnSubscriptionsListed$ = this._actions.ofType(ON_SUBSCRIPTIONS_LISTED)
  .do(action => console.log(`${action.payload.length} subscriptions listed.`)

/ * This was the effect in question.
    I've grouped it with the other subscription effects because I believe it
    will be more natural for someone trying to understand how subscriptions
    get filled to find it here in the future. 
*/
@Effect() OnIdentityAuthorized$ = this._actions.ofType(ON_IDENTITY_AUTHORIZED)
  .switchMap(identity => this._subscriptionActions.ListSubscriptions(identity))

Очевидно, мне все равно хотелось бы, чтобы кто-то с большим опытом работы с шаблоном @Effects в средних/крупных проектах присоединился к нам.

person josh-sachs    schedule 20.03.2017