Ngrx dispatch与select机制解析
在ngrx状态管理中，this.store.select()用于订阅并观察应用程序状态的特定切片，当该切片发生变化时，订阅的回调函数会被执行。而this.store.dispatch()则是触发状态变更的唯一途径，它会发送一个action，进而由reducer处理并更新状态。
考虑以下代码片段，它展示了在select订阅的回调函数中连续调用dispatch操作：
import { Subscription } from 'rxjs';
import { Store } from '@ngrx/store';
import { Router, ActivatedRoute } from '@angular/router';
import { OnInit, OnDestroy, Component } from '@angular/core';
// 假设的Ngrx状态接口和Actions
interface countriesState {
region: string;
Status: boolean;
// ... 其他状态属性
}
interface TestState {
countriesState: countriesState;
}
// 假设的Actions（实际Ngrx中应定义为类或工厂函数）
class Action1 { readonly type = 'Action1'; }
class Action2 { readonly type = 'Action2'; }
@Component({
selector: 'app-region',
template: ``
})
export class RegionComponent implements OnInit, OnDestroy {
storeSubscriptions: Subscription[] = [];
region: string; // 用于存储从状态中获取的region
constructor(private store: Store, private router: Router, private route: ActivatedRoute) {}
ngOnInit() {
this.storeSubscriptions.push(
this.store.select(locationState => locationState.countriesState).subscribe(state => {
this.region = state.region;
if (state.Status === true) {
// 潜在的无限循环点
this.store.dispatch(new Action1());
this.store.dispatch(new Action2());
this.router.navigate(['/confirm-region'], { relativeTo: this.route.parent });
}
})
);
}
ngOnDestroy() {
this.storeSubscriptions.forEach(sub => sub.unsubscribe());
}
} 这段代码的意图是当countriesState中的Status变为true时，执行一系列Action并导航到新路由。然而，这种模式如果不加注意，极易导致无限循环。
dispatch的同步性探究
一个常见的问题是：this.store.dispatch()是否是同步函数？当连续调用多个dispatch以及其他函数时，它们的执行顺序如何？
答案是：this.store.dispatch()本身是一个同步函数调用。这意味着当你调用它时，它会立即将Action发送到Ngrx的管道中，然后立即返回，允许后续的代码继续执行。
考虑以下序列：
this.store.dispatch(new Action1());
this.store.dispatch(new Action2());
this.router.navigate(['/confirm-region'], { relativeTo: this.route.parent });在这个序列中：
- this.store.dispatch(new Action1())会被调用并立即返回。
- this.store.dispatch(new Action2())紧接着被调用并立即返回。
- this.router.navigate(...)随后被调用并执行导航逻辑。
因此，router.navigate语句会被调用。尽管dispatch是同步发起的，但由Action触发的状态更新（通过Reducer）以及Ngrx Effects的执行是异步的（通常通过RxJS的调度器）。这意味着，在router.navigate执行时，Action1和Action2可能还没有完全处理完毕，或者状态还没有完全更新并通知所有订阅者。
无限循环的成因与风险
无限循环的风险在于，如果Action1或Action2（或其后续Effect）修改了countriesState，并且这种修改导致this.store.select(locationState => locationState.countriesState)再次发射一个满足if (state.Status === true)条件的新值，那么订阅的回调函数将再次执行，再次dispatch Action1和Action2，从而形成一个无限循环。
例如：
- countriesState.Status变为true。
- select订阅回调执行。
- dispatch(new Action1())和dispatch(new Action2())。
- 假设Action1或Action2的Reducer逻辑没有改变countriesState.Status的值，或者将其改回true。
- countriesState更新，select再次发射（因为状态对象引用可能改变，即使Status值未变）。
- 订阅回调再次执行，条件state.Status === true再次满足。
- 循环继续...
在原始代码示例中，router.navigate实际上是这个潜在无限循环的“救星”。当路由发生变化时，RegionComponent很可能会被销毁。组件销毁时，ngOnDestroy钩子会被调用，其中包含this.storeSubscriptions.forEach(sub => sub.unsubscribe())，这会取消对store.select的订阅，从而中断无限循环。然而，这是一种副作用而非可靠的设计，过度依赖路由来中断循环是不可取的。
规避无限循环的策略与最佳实践
为了构建健壮且可预测的Ngrx应用，我们应主动规避此类无限循环。
策略一：条件化dispatch操作
在select订阅的回调中dispatch Action时，必须确保有明确的条件来防止重复执行。这通常涉及在状态中引入一个标志位，或者利用RxJS操作符来过滤掉不必要的重复。
示例：引入状态标志位
import { Subject, Subscription } from 'rxjs';
import { takeUntil, distinctUntilChanged } from 'rxjs/operators';
// ... 其他导入 ...
// 假设Actions现在是Ngrx Action Creator
import * as CountriesActions from './countries.actions'; // 例如：定义了 Action1, Action2, ActionsProcessed
// 修改后的countriesState接口，增加一个处理标志
interface countriesState {
region: string;
Status: boolean;
actionsProcessedForStatusTrue: boolean; // 新增标志位
}
// ... RegionComponent 保持不变，但 ngOnInit 内部逻辑修改 ...
ngOnInit() {
this.storeSubscriptions.push(
this.store.select(locationState => locationState.countriesState).pipe(
// 只有当Status或actionsProcessedForStatusTrue变化时才触发
distinctUntilChanged((prev, curr) =>
prev.Status === curr.Status && prev.actionsProcessedForStatusTrue === curr.actionsProcessedForStatusTrue
)
).subscribe(state => {
this.region = state.region;
// 关键：只有当Status为true且尚未处理时才dispatch
if (state.Status === true && !state.actionsProcessedForStatusTrue) {
this.store.dispatch(CountriesActions.action1()); // 使用Action Creator
this.store.dispatch(CountriesActions.action2());
this.router.navigate(['/confirm-region'], { relativeTo: this.route.parent });
// dispatch一个Action来更新状态中的标志位，避免下次select再触发
this.store.dispatch(CountriesActions.actionsProcessedForStatusTrue());
}
})
);
}
// ... ngOnDestroy 保持不变 ...在上述示例中，我们引入了actionsProcessedForStatusTrue这个状态标志位。当Status变为true且相关Action尚未处理时，才dispatch Action1和Action2，并立即dispatch一个Action来更新actionsProcessedForStatusTrue为true。这样，即使Status保持true，下一次select发射时，条件!state.actionsProcessedForStatusTrue将不再满足，从而避免循环。
策略二：Ngrx Effects 的应用
对于复杂的副作用逻辑，Ngrx Effects是更推荐的处理方式。Effects监听特定的Action，执行异步操作（如API调用），然后dispatch新的Action来更新状态。这将副作用逻辑从组件中解耦，使得组件只负责dispatch Action和select状态，避免在select回调中进行复杂的dispatch链。
示例：使用Ngrx Effect处理导航和后续Action
-
定义一个触发Action：
// countries.actions.ts import { createAction } from '@ngrx/store'; export const statusBecameTrue = createAction('[Countries] Status Became True'); export const action1 = createAction('[Countries] Action 1 Triggered'); export const action2 = createAction('[Countries] Action 2 Triggered'); export const navigateToConfirmRegion = createAction('[Countries] Navigate To Confirm Region'); -
在组件中只dispatch一个意图Action：
// region.component.ts // ... ngOnInit() { this.storeSubscriptions.push( this.store.select(locationState => locationState.countriesState).pipe( // 确保只有当Status从false变为true时才触发 distinctUntilChanged((prev, curr) => prev.Status === curr.Status), filter(state => state.Status === true) // 只关心Status变为true的情况 ).subscribe(state => { this.region = state.region; // 只dispatch一个意图Action this.store.dispatch(CountriesActions.statusBecameTrue()); }) ); } // ... -
创建Effect来处理后续逻辑：
// countries.effects.ts import { Injectable } from '@angular/core'; import { Actions, createEffect, ofType } from '@ngrx/effects'; import { Router } from '@angular/router'; import { tap } from 'rxjs/operators'; import * as CountriesActions from './countries.actions'; @Injectable() export class CountriesEffects { constructor(private actions$: Actions, private router: Router) {} statusBecameTrueEffect$ = createEffect(() => this.actions$.pipe( ofType(CountriesActions.statusBecameTrue), // 在这里可以dispatch Action1和Action2，或者直接处理导航 tap(() => this.store.dispatch(CountriesActions.action1())), // 假设Action1也需要被dispatch tap(() => this.store.dispatch(CountriesActions.action2())), // 假设Action2也需要被dispatch tap(() => this.router.navigate(['/confirm-region'])) // 处理导航 // 如果需要dispatch一个Action来表示导航已完成，可以在这里添加 ), { dispatch: false } // 因为我们在这里直接处理了导航和dispatch，所以这个Effect本身不dispatch新的Action ); }通过Effects，我们清晰地分离了“响应状态变化”和“执行副作用”的逻辑，使代码更易于理解和维护，并有效避免了组件内部的dispatch循环。
策略三：严格的订阅管理
无论采用何种dispatch策略，严格管理RxJS订阅都是Ngrx应用中的一项基本要求。未取消的订阅会导致内存泄漏，并且在组件销毁后仍然可能触发回调，引发难以预料的行为。
在Angular组件中，最常见的订阅管理方式是在ngOnDestroy钩子中取消所有订阅。推荐使用takeUntil操作符配合一个Subject来简化此过程。
示例：使用takeUntil管理订阅
import { Subject, Subscription } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
// ... 其他导入 ...
@Component({
selector: 'app-region',
template: ``
})
export class RegionComponent implements OnInit, OnDestroy {
private destroy$ = new Subject(); // 用于takeUntil操作符
// ... 其他属性和构造函数 ...
ngOnInit() {
this.store.select(locationState => locationState.countriesState).pipe(
takeUntil(this.destroy$) // 在destroy$发射时自动取消订阅
// ... 其他RxJS操作符，如distinctUntilChanged, filter ...
).subscribe(state => {
this.region = state.region;
// ... 条件化dispatch逻辑 ...
});
}
ngOnDestroy() {
this.destroy$.next(); // 发射一个值
this.destroy$.complete(); // 完成Subject
}
} 这种方法确保了当RegionComponent被销毁时，所有通过takeUntil(this.destroy$)连接的订阅都会自动取消，从而避免内存泄漏和不必要的逻辑执行。
总结
在Ngrx状态管理中，理解dispatch的同步执行特性至关重要，它确保了代码的顺序执行。然而，在select订阅回调中dispatch Action时，必须高度警惕无限循环的风险，特别是当这些Action会再次影响被观察的状态时。
为了构建稳定、可维护的Ngrx应用，我们应该：
- 谨慎使用条件判断： 在select回调中dispatch Action时，确保有明确的条件来防止重复触发，例如引入状态标志位。
- 优先使用Ngrx Effects： 对于复杂的副作用处理，将其封装在Effects中，以实现逻辑解耦和更好的可测试性。
- 严格管理RxJS订阅： 始终在组件销毁时取消
