如何解决NGRX效果:可观察到的Firebase auth的switchMap / exhaustMap导致效果运行两次
我一直在跟踪代码中的重复注销操作;花了很长时间来缩小范围。这实际上可能不是问题,可能很琐碎,这对我来说有点困惑。
在exhaustMap(以前使用过的switchMap)this.afAuth.authState.pipe
中创建的可观察对象在用户登录后保持活动状态,因此,当用户注销时,它将再次推送并重新运行其管道中的代码,最终记录userNotAuthenticated操作。退出操作的结果也分派了此操作(哪种IMO是更改用户状态的首选方式?)
getUser$ = createEffect(() => {
return this.actions$.pipe(
ofType(userActions.getUser),tap(a => console.log("getUser pre switch: ",a)),exhaustMap(
action => this.afAuth.authState.pipe( // <----
tap(a => console.log("getUser :: auth state ",map(authData => {
if (authData) {
const user = {
uid: authData.uid,displayName: authData.displayName,email: authData.email,photoUrl: authData.photoURL,} as User
console.log("getUser > auth suc")
return userActions.userAuthenticated({ user });
} else {
console.log("getUser > auth fail: ",authData);
return userActions.userNotAuthenticated({});
}
}),catchError(
error => of(userActions.userAuthError({ error }))
)
)
),tap(a => console.log("getUser post switch: ",})
考虑到exhaustMap的工作原理,这很有意义。我可以通过不返回userNotAuthenticated动作并再次让fire authState管道运行以自动调度userNotAuthenticated来解决此问题,但是似乎可以观察到的滞后动作和反应性行为会违背Redux和良好状态管理的设计原则? (但可能不是吗?)在authState管道中使用take(1)
第一件事也是可行的。可以想象,身份验证可能会从Google的末端强制终止,也许还有其他我可能不了解的更新。
最终,我可以保持原样。在这种情况下,重复动作是微不足道的,因为它们是幂等的。至少我已经了解了为什么我不应该重复使用动作(Good Action Hygiene with NgRx Mike Ryan)。我已经重命名了它们,它们是不同的动作,但是共享了reducer逻辑,因此仍然处于冗余状态。奇怪的是,我见过的每个教程/示例/ github项目都使用相同的精确方法。也许firebase在推送authstate的方式上是独特的,但是我想得越多,authState可观察者将在用户登录的整个生命周期内推送的意义就越大(注销后观察者似乎完成了,因为效果没有不会与更多的getUser调用相乘)。
我应该完全关心它的工作方式吗?我进行了很多搜索,甚至找不到任何描述这种行为的人。我认为保留它可能是最好的选择,但是我真的很难尝试预测一种解决方案比另一种更可取的边缘情况。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。