React Redux中用Reducer更新CurrentState存储计算结果是否为反模式？

Great question! Let's unpack your two approaches and whether the second one falls into anti-pattern territory.

First, Let's Recap Your Two Options #

• Option 1: View-layer calculations
  You run map, filter, or find directly in your components whenever they render.

  • Upsides: Super simple, keeps your Redux state focused on being the single source of raw truth. No extra complexity in your reducers.
  • Downsides: Can waste resources if you're re-running these calculations on every render—especially with large datasets or components that re-render frequently.

• Option 2: Precomputed state in Redux
  You maintain a CurrentState object in your store, where reducers handle the filtering/mapping and store the final result.

  • Upsides: Cuts down on redundant computations; components can grab the precomputed data immediately, which boosts performance.
  • Downsides: Risks state duplication if you're not careful, and can make your reducers a bit more complex to write.

Is Option 2 an Anti-Pattern? #

Short answer: Absolutely not. This is a valid performance optimization strategy, and it's even referenced in Redux's official documentation as a standard approach for scenarios where repeated calculations become a bottleneck.

That said, there are a few rules to follow to avoid common pitfalls:

• Only optimize when you need to: Don't precompute every possible derived state "just in case". Reserve this for situations where you've actually identified a performance issue (like filtering a list of 1000+ items on every render).
• Keep your raw state as the single source of truth: Never let your CurrentState get updated independently of the raw data it's derived from. Always recalculate CurrentState directly from the raw state in your reducers whenever the raw data changes. This prevents bugs from duplicated, out-of-sync state.
• Consider memoized selectors first: Before jumping to storing precomputed state in reducers, check out memoized selectors (like those from the reselect library). These compute derived state on demand but cache the result, so they only re-run when the underlying raw state changes. They give you the performance benefit without cluttering your reducers with extra state management.

When to Pick Which Approach #

• Go with Option 1 if you're working with small datasets or components that don't re-render often. The simplicity is way more valuable than micro-optimizations here.
• Go with Option 2 if you have large datasets, frequent re-renders, or if memoized selectors don't quite fit your use case (e.g., you need the precomputed state to be available across multiple unrelated components). Just make sure you're strictly deriving CurrentState from your raw source state every time it updates.

Final Thought #

Storing precomputed derived state in your Redux reducers is totally acceptable—it's not an anti-pattern. The key is to do it intentionally (for performance reasons, not just habit) and to keep your source state clean and authoritative. Memoized selectors are often a great middle ground, but both approaches have their place in a well-designed Redux app.

内容的提问来源于stack exchange，提问作者Cisum Inas