ComponentStore and NgRx Store: Cross-Feature Workflow State Boundary

Cross-Feature Workflow State Boundary: ComponentStore vs NgRx Store

Teams building Angular features with NgRx often need to manage workflow state that spans multiple concerns, such as form progression, validation state, or UI flags that interact with domain data. The interoperability between @ngrx/store and @ngrx/component-store offers a path to separate local UI state from shared domain state, but the appropriate boundary for cross-feature workflow state remains an open design decision.

Likely explanation

ComponentStore state is scoped to its provider. When provided at the component level, state resets on navigation away from that component, making it suitable for ephemeral UI transients. Global Store slices persist for the application lifetime, which makes them natural candidates for cross-feature workflow state that must survive navigation or be shared across features.

Confirmed facts from NgRx version considerations

• NgRx 16.x uses observable-based Store and @ngrx/component-store APIs; state declaration and effect registration follow traditional patterns.
• NgRx 17.x introduces SignalStore and signal-based APIs; workflow state can be declared as signals, with computed effects for syncing to domain state.
• Providing ComponentStore in a shared module or root keeps state alive across navigation; providing it per-component resets it.

Recommended boundary pattern

Store cross-feature workflow state (form progression, validation flags) in a dedicated feature slice of the global NgRx Store, accessed via selectors. Use ComponentStore only for component-scoped UI transients that are intentionally ephemeral and reset on navigation. When workflow state needs to persist, commit a snapshot from ComponentStore into the global Store on completion.

To prevent ComponentStore local state from drifting out of sync with global selectors, derive UI flags from domain state selectors rather than maintaining parallel state, or use ComponentStore as a thin adapter that feeds values into the global slice on commit.

Verification step: Inspect the NgRx Store devtools extension. Confirm that workflow state appears as a persistent slice rather than component-scoped state that clears on navigation. Check the provider scope in your app module or feature module to understand persistence behavior.

Missing detail for refined recommendation: Is ComponentStore provided at the root/shared module level or per-component? This determines whether state survives navigation and whether a persistence strategy to global store is required.