如何在 Angular 中有效管理状态

状态管理是决定 Angular 应用能否优雅扩展还是沦为维护噩梦的关键。然而,大多数开发者都在纠结一个基本问题:什么时候应该使用 Signals、服务、RxJS 还是 NgRx?

本文提供了一个实用框架,帮助你根据实际需求(而非理论最佳实践)选择正确的 Angular 状态管理方法。我们将探讨 Angular Signals 的优势场景、基于服务的 RxJS 的适用情况,以及何时需要 NgRx 或 SignalStore。

理解 Angular 应用中的状态作用域

在选择工具之前,先要理解状态的作用域。Angular 应用通常有三个不同的状态层级,每个层级需要不同的管理策略。

局部组件状态

局部状态与单个组件共存亡。比如表单输入、UI 开关或临时计算。对于这些场景,Angular 组件状态最佳实践倾向于简单性:使用 Signals 管理响应式状态,或使用普通类属性管理静态值。

@Component({
  selector: 'app-product-card',
  template: `
    <div [class.expanded]="isExpanded()">
      <button (click)="toggle()">{{ isExpanded() ? 'Less' : 'More' }}</button>
    </div>
  `
})
export class ProductCardComponent {
  isExpanded = signal(false);
  
  toggle() {
    this.isExpanded.update(v => !v);
  }
}

共享功能状态

当一个功能模块内的多个组件需要相同数据时,服务就成为你的协调中心。一个同时出现在头部、侧边栏和结账页面的购物车需要集中管理——但不一定需要全局状态库。

全局应用状态

身份认证状态、用户偏好设置和应用级通知会影响整个应用。这就是在 Angular 中管理全局状态需要仔细权衡复杂性与可维护性的地方。

Angular Signals:响应式状态的现代默认选择

自 Angular 16 起,Signals 提供了细粒度的响应式能力,而无需 observables 的复杂性。它们在同步状态更新和计算值方面表现出色。

Signals 的优势场景

在以下需要响应式状态的场景中使用 Signals:

• 同步更新
• 高效派生计算值
• 与 Angular 变更检测无缝集成

@Injectable({ providedIn: 'root' })
export class CartService {
  private items = signal<CartItem[]>([]);
  
  // 计算信号自动更新
  total = computed(() => 
    this.items().reduce((sum, item) => sum + item.price * item.quantity, 0)
  );
  
  addItem(item: CartItem) {
    this.items.update(items => [...items, item]);
  }
}

关键优势?Signals 消除了常见的 RxJS 陷阱,如订阅管理和内存泄漏,同时通过细粒度更新提供更好的性能。

基于服务的 RxJS 状态管理

对于异步操作和复杂数据流,RxJS observables 仍然不可或缺。Angular Signals 与 NgRx 的对比讨论常常忽略了这个中间地带:基于服务的 RxJS 可以处理许多实际场景,而无需引入框架开销。

结合 Signals 和 RxJS

现代 Angular 应用通常受益于混合方法:

@Injectable({ providedIn: 'root' })
export class UserService {
  private currentUser = signal<User | null>(null);
  
  // 暴露为只读信号
  user = this.currentUser.asReadonly();
  
  constructor(private http: HttpClient) {}
  
  loadUser(id: string) {
    return this.http.get<User>(`/api/users/${id}`).pipe(
      tap(user => this.currentUser.set(user)),
      catchError(error => {
        this.currentUser.set(null);
        return throwError(() => error);
      })
    );
  }
}

这种模式让你既能享受 Signal 存储状态的简单性,又能利用 RxJS 处理异步操作的强大能力。

NgRx 和 SignalStore:当复杂性需要结构化时

当你有真正复杂的状态需求时,NgRx 就显得很有意义:多用户协作、乐观更新、时间旅行调试或广泛的跨功能协调。

NgRx SignalStore:轻量级替代方案

NgRx SignalStore 和 Signals 的结合提供了结构化而无需样板代码。SignalStore 提供状态管理模式,同时利用 Angular 原生 Signal 的性能优势:

export const CartStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withComputed((state) => ({
    itemCount: computed(() => state.items().length),
    isEmpty: computed(() => state.items().length === 0)
  })),
  withMethods((store) => ({
    addItem: (item: CartItem) => 
      patchState(store, { items: [...store.items(), item] }),
    clear: () => 
      patchState(store, { items: [] })
  }))
);

SignalStore 为那些需要比服务更多结构但又不想要传统 NgRx 繁文缛节的应用找到了最佳平衡点。

做出正确选择:实用决策框架

不要再问”哪种状态管理最好?“,而是开始问”这个特定状态需要什么?”

直接使用 Signals 的场景:

• 状态是同步且局部的
• 需要计算值
• 频繁更新时性能很重要

使用基于 Signals/RxJS 的服务的场景:

• 多个组件共享状态
• 处理异步操作
• 状态逻辑是功能特定的

考虑 NgRx SignalStore 的场景:

• 需要跨团队的一致模式
• 状态交互变得复杂
• 想要结构化但不要完整的 Redux

采用传统 NgRx 的场景:

• 构建有严格要求的企业应用
• 多个开发者需要可预测的模式
• 需要 DevTools、时间旅行调试或副作用管理

需要避免的常见陷阱

Angular 状态管理中最大的错误不是选错工具——而是过度设计。不要把每个计数器都放进 NgRx。不要为组件专属状态创建服务。不要在 Signals 就足够的时候使用 RxJS。

从简单开始。当组件需要共享状态时再提取到服务。当服务变得难以管理时再引入状态库。这种渐进式方法可以防止设计不足和过度设计。

结论

Angular 中的有效状态管理不是为所有场景选择一种方法。现代 Angular 应用依靠分层策略蓬勃发展:Signals 用于局部响应性,服务用于共享逻辑,状态库用于复杂协调。

以 Signals 作为默认选择。当需要共享时转向服务。将 NgRx(无论是传统版还是 SignalStore)留给真正复杂的状态挑战。这种务实的方法能保持代码库的可维护性,同时避免过早优化。

最好的状态管理策略是能解决实际问题的最简单方案。

常见问题

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.