为何选择@ngrx/createSelector而非Observable.combineLatest？

Great question—this is a common point of confusion when first diving into NgRx selectors, and you’re right to dig into the tradeoffs. Let’s break down why createSelector is still the better choice for NgRx-based apps, even when you think combineLatest with distinct checks might cover the bases.

1. Smart, Dependency-Aware Memoization (Not Just Shallow Comparisons) #

Your hunch about memoization being key is correct, but you’re missing how NgRx’s memoization works specifically with immutable state (a core NgRx best practice):

• createSelector tracks the output of each input selector (like selectUser and selectAllBooks) using strict equality (===). Since NgRx encourages immutable state updates, any change to selectedUser or allBooks will result in a new reference (not just modified internal properties). This means the memoization cache will only invalidate when the actual state slices change—no false positives or missed updates.
• With combineLatest + distinctUntilChanged, you’d have to choose between:
  • Default shallow comparison: Misses internal property changes if references stay the same (violating immutability principles anyway).
  • Custom deep comparison (e.g., Lodash’s isEqual): Adds unnecessary performance overhead, as you’re comparing entire objects/arrays on every emission, even when nothing relevant changed.

2. Seamless Selector Composition #

createSelector is built for reusability and composition—something combineLatest can’t match natively:

• You can nest selectors to build complex derived state without rewriting logic. For example, you could reuse selectVisibleBooks in another selector:

  export const selectVisibleBookTitles = createSelector(
    selectVisibleBooks,
    (books) => books.map(book => book.title)
  );
  

• combineLatest returns an Observable, which can’t be directly used as an input to another selector. This forces you to either wrap Observables in selectors (adding boilerplate) or nest combineLatest calls, leading to messy, hard-to-maintain code.

3. Automatic Subscription Management #

When you use createSelector with NgRx’s store.select(), NgRx automatically manages subscriptions to all dependent selectors:

• It only subscribes to the state slices your selector actually needs, avoiding redundant subscriptions to unrelated parts of the store.
• With combineLatest, you’re responsible for managing subscriptions manually—this increases the risk of memory leaks (if you forget to unsubscribe) or unnecessary emissions from over-subscribed Observables.

4. Clear Intent & Context #

createSelector explicitly signals "this is logic for deriving state from the NgRx Store" to other developers. This makes your codebase more readable and maintainable, especially in teams:

• A combineLatest implementation could be used for any RxJS stream combination, not just NgRx state. It doesn’t carry the same semantic meaning, making it harder to reason about at a glance.

5. Optimized for NgRx’s Immutable State Model #

NgRx’s entire ecosystem is built around immutable state updates. createSelector leverages this by design:

• When you update the store (e.g., via reducers), you always return new objects/arrays. This ensures that createSelector’s memoization works reliably—no need for workarounds to detect changes.
• If you were to use mutable state with createSelector, you’d run into issues, but that’s a violation of NgRx’s best practices, not a flaw in the selector system.

Wrap-Up #

While combineLatest + distinctUntilChanged can replicate some of createSelector’s behavior, it requires extra boilerplate, introduces performance tradeoffs, and doesn’t integrate seamlessly with the rest of the NgRx ecosystem. createSelector is purpose-built to make derived state logic efficient, reusable, and maintainable in NgRx apps.

内容的提问来源于stack exchange，提问作者Kesem David