NGRX：聆听按特定顺序派遣的动作链是一个反对者吗？
我发现以下模式有用和通用：
effectXY$ = createEffect(() =>
this.actions$.pipe(
ofType(actionX, actionY),
switchMap(() =>
this.myApi.something()
.pipe(
map(() => actionZ())
)
)
)
);
effectXZ$ = createEffect(() =>
this.actions$.pipe(
ofType(
actionX,
actionZ
),
pairwise(),
// wait for both actions to be dispatched in the correct order
filter( ([prevAction, currentAction]) =>
prevAction.type === actionX.type &&
currentAction.type === actionZ.type
),
map(() => actionA())
)
);
发生的事情是，actiona仅在actionx和actionz 才被调用。 。这样做我还避免创建许多其他动作来模仿这种模式，但是我错过了这可能会导致
编辑的任何含义：提醒您没有保证这些动作是连续的（没有其他动作在介于两者之间）
I find the following pattern usefull and versatile:
effectXY$ = createEffect(() =>
this.actions$.pipe(
ofType(actionX, actionY),
switchMap(() =>
this.myApi.something()
.pipe(
map(() => actionZ())
)
)
)
);
effectXZ$ = createEffect(() =>
this.actions$.pipe(
ofType(
actionX,
actionZ
),
pairwise(),
// wait for both actions to be dispatched in the correct order
filter( ([prevAction, currentAction]) =>
prevAction.type === actionX.type &&
currentAction.type === actionZ.type
),
map(() => actionA())
)
);
What is happening is that actionA is dispatchen only if actionX and actionZ have been dispatched in that specific order. Doing this i also avoid to create lots of other actions to mimic this pattern, but i miss whatever implications this might lead to
edit: reminder that there is no guarantee that the actions are consecutive (with no other actions being dispatched in between)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这里没有明显的反诉讼。您正在按书做所有事情。
您可以使用效果来观察
操作$流，使用RXJS操作员从中挑选的RXJS操作员是一种与您的条件匹配的特定事件，并在发生该事件时返回操作。如果没有更多关于您实际试图使用此代码在应用程序中完成的工作的背景，我看不到从原始理论的角度来看的理由来批评它。
There is no obvious anti-pattern here. You're doing everything by the book.
You use your Effect to observe the
actions$stream, using RxJs operators you pick from it a specific kind of event that matches your criteria, and return an Action when that event happens.Without more context as to what you're actually trying to accomplish in your app with this code, I don't see grounds to criticize it from the raw theory standpoint.