NgRx is an option for Angular applications that need state shared across features, retained through navigation, hydrated, or coordinated across multiple event sources—not a requirement for every app. Its Store makes state changes explicit through actions, reducers, selectors, and, when needed, effects. That structure can improve coordination and testability, but it adds concepts and code, so keep state local when the feature does not need a wider boundary.
When should you use NgRx Store?
NgRx’s SHARI checklist is a practical way to decide whether a global Store solves a real problem. It is a decision heuristic, not a formal standard or a performance benchmark. Consider Store when state is:
As an Amazon Associate I earn from qualifying purchases.
- Shared: used by multiple components or services that need a consistent view.
- Hydrated: saved and restored, for example across a reload or session boundary.
- Available: expected to remain accessible when a user leaves a route and returns.
- Retrieved: loaded through asynchronous work such as an API request.
- Impacted: changed by events from multiple sources that must be coordinated.
The case for Store is strongest when several of these apply together. If state belongs to one component, is short-lived, and has no wider coordination needs, a global action stream may create more maintenance work than value. NgRx itself describes Store as a controlled state container and acknowledges that it is not the shortest or quickest route for writing an application. See NgRx’s guidance on why to use Store.
How do actions, reducers, selectors, and effects fit together?
Store is an event-driven state container. An action names something that happened; a reducer calculates the next state; a selector reads or derives data for consumers; and an NgRx effect handles external interactions when those belong outside the reducer and UI. The documented processing order matters: reducers process an action before effects handle it. Reducers must remain pure state-transition functions; an API call or other external operation does not belong inside one.
#1 Best Overall
- A component or service dispatches an action describing an event, such as a user requesting a book list.
- Reducers receive the action and return the next immutable state.
- Selectors expose the relevant state or derive a view from one or more state slices.
- If the event requires external work, an NgRx effect can respond to the action, interact with that external system, and dispatch a result action for reducers to process.
- Views consume selected state and dispatch further actions in response to user intent.
This separation makes it easier to see what changed state and to test transitions independently. It also gives API interactions a defined boundary when an application needs one. Not every asynchronous request must be implemented as an effect: the appropriate choice depends on the feature’s coordination needs. NgRx’s Store guide explains the concepts and processing order.
How do you build a Store feature in Angular?
A useful implementation sequence is to decide what belongs in the state shape, define meaningful events, write pure transitions, register the Store, and connect views through selectors and dispatches. Add effects where external interactions need a clear boundary. The current v21 walkthrough demonstrates provider-based setup; use the application configuration pattern appropriate to your Angular app.
- Define the state shape. Keep the state to the information the feature needs to retain. Prefer one canonical representation of an entity over duplicated copies that can drift.
- Name events with actions. Actions should describe events or intent, rather than encode arbitrary state mutation instructions.
- Write reducers. Handle relevant actions with pure functions that return new state rather than mutating existing state.
- Register Store providers. In a provider-based Angular application, configure the root Store with
provideStorein application setup, following the NgRx v21 Store walkthrough. - Select data for views. Use selectors for reusable projections and composed results; components should consume the values they need, not reimplement state derivation.
- Dispatch where intent occurs. A view or service dispatches an action when a user or system event happens.
- Add effects when appropriate. Put network and other external interactions behind effects when that improves coordination and separation from the UI.
Derive views instead of duplicating data
Suppose state contains a list of books and a separate collection of selected book IDs. A selector can join those slices to produce the selected books for a view. Keeping IDs as the selection representation avoids storing a second full set of book objects that could become stale. This is one useful normalized model, not a rule that every feature must use the same shape.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsKeep tutorials and production boundaries in perspective
The NgRx v21 walkthrough uses a simple service subscription in its example and notes that a fuller application would probably handle the request through effects. That simplification helps demonstrate Store concepts; it does not mean every tutorial subscription is the best boundary for a larger feature.
Rank #3
Should state stay local, use ComponentStore, or go in global Store?
Choose the smallest state boundary that meets the feature’s sharing and lifecycle needs. NgRx offers more than one option, and neither a global Store nor a signal-based API is universally best.
| Option | Good fit | Trade-off to consider |
|---|---|---|
| Component or local signal state | Temporary state used within one component or a tightly bounded view. | Does not by itself provide a shared, application-wide event stream. |
| ComponentStore | State scoped to a component or feature boundary that needs state-management APIs without making that state global. | Scope and lifetime should still match who needs the state; it is not a substitute for a genuinely shared global source. |
| SignalStore or NgRx Signals | A signal-oriented approach when a feature benefits from signal-based state APIs. | Do not choose it merely because the word “signal” appears in the API; evaluate the feature’s sharing, lifecycle, and coordination requirements. |
| Global NgRx Store | State shared across distant parts of an app, retained or hydrated, or affected by several sources and workflows. | Introduces additional files and Redux/RxJS concepts, so the team must be willing to maintain that structure. |
The Store guide points readers toward NgRx Signals for temporary or local component state. That is guidance about fit, not a claim that Store cannot represent local state. ComponentStore’s API documentation describes its scoped state APIs, while NgRx v21 Signals installation guidance covers the signal-oriented path.
When does NgRx Entity help?
NgRx Entity is intended to reduce repetitive work around collections. Its typed adapters provide common collection operations and selectors while keeping state as plain objects. It can be useful when a feature repeatedly adds, removes, updates, or selects entities and hand-written reducer cases are becoming boilerplate. It is a collection helper, not a requirement for every array or a measured guarantee of faster application performance. See the NgRx Entity guide.
NgRx Store effects and Angular effects are different
The shared word “effect” can be confusing. An NgRx Store effect listens to actions and is commonly used to isolate interactions such as API calls from components. An Angular effect is part of Angular’s signals API, intended for synchronization with imperative, non-signal APIs. Angular advises using computed or linkedSignal for derived state rather than using an Angular effect to copy one signal’s value into another. Their roles and execution contexts are distinct; consult Angular’s effects guide and effect API reference for lifecycle and scheduling details.
What is the status of NgRx Data?
NgRx Data is a separate abstraction from Store and Entity. Its architecture documentation describes a workflow for entity data, but the package’s architecture overview says @ngrx/data is in maintenance mode, with changes limited to critical bug fixes. That status applies to NgRx Data specifically; it should not be generalized to Store, Signals, Entity, or the entire NgRx project. For new architecture, do not assume NgRx Data is the default choice without accounting for that maintenance status. Read the NgRx Data architecture overview and NgRx Data architecture documentation.
Quick Recap
A practical decision checklist
- Can the state remain inside one component or feature without duplication or awkward communication? Prefer the smaller boundary.
- Do multiple parts of the app need the same state, or must it remain available after navigation? A scoped or global state solution may be justified.
- Do several event sources change the same data, or does the feature need a shared action stream and observable transitions? Global Store may provide useful coordination.
- Does the team need explicit reducer transitions, reusable selectors, and a defined external-work boundary enough to justify the extra concepts and files?
- Would Entity meaningfully reduce repetitive collection logic, or would it add an abstraction around a collection that is already simple?
- Is a proposed design based on NgRx Data? Check its documented maintenance status before making it a new default.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
