NgRx Platform: Angular State Management with Store, Effects and Signals

What NgRx Solves That Angular Services Do Not

Angular gives you services and dependency injection, and for a single feature that is usually enough. The problem appears when state is shared across routes and components: a service holding a mutable object gives no record of why it changed, no single place to replay or log transitions, and no rule about who may write. NgRx answers that with a store that is read-only from the outside. Components dispatch actions; pure functions called reducers compute the next state; selectors read slices of it. The README describes the project plainly as "Reactive State for Angular", and the repository is a monorepo of packages under the @ngrx scope rather than one library. Store is the core. Effects handle side effects such as HTTP calls. Entity provides adapters for collections. Component Store targets local, component-scoped state rather than global state. The audience is Angular teams that have already felt the pain of inconsistent state and are willing to pay in boilerplate to remove it.

How the Store, Effects and Selectors Fit Together

The data flow is one-directional and enforced by the API shape. A component dispatches an action object. Reducers, which are pure functions, receive the current state and the action and return a new state; nothing mutates the existing one. Selectors are memoized functions that project from the state tree, so a component subscribes to a derived value rather than the whole store. Effects sit beside the reducer, not inside it: they listen for dispatched actions, perform the impure work (a network request, a storage write), and dispatch new actions with the result. That separation is the whole design argument. Reducers stay testable because they contain no I/O, and side effects stay visible because they are declared as streams rather than hidden inside a method. The repository topics list signals alongside observables and RxJS, and the monorepo layout under projects/ and modules/ reflects that the packages are built and versioned together. Whether a given signal-based API is available to you depends on the version you install; ngrx.io is the reference the README points to, and the README itself documents no API surface.

Installing NgRx and Dispatching Your First Action

The README does not contain install steps; it points to ngrx.io for documentation and lists @ngrx/store on npm. The repository's package.json is the monorepo manifest for @ngrx/platform at version 22.0.1, not the package an application installs. In an Angular workspace the schematics-driven route is the documented one, and the underlying package is @ngrx/store. A minimal store setup looks like this:

What the Monorepo Layout Tells You About Upgrade Cost

NgRx is not one package. The workspace publishes @ngrx/store, @ngrx/effects, @ngrx/entity, @ngrx/component-store, @ngrx/router-store, @ngrx/store-devtools and others from the same repository, and package.json shows the whole set is built and released together with nx run-many --target=build --all. That is convenient when you want a coherent version line and inconvenient when you only need one piece. The repository carries a MIGRATION.md file and the package scripts include nx migrate latest and ng update, which is the documented path for version bumps rather than hand-editing dependency ranges. The engines field requires Node ^22.22.3 || ^24.15.0 || >=26.0.0 and pnpm ^11.0.0 to build the monorepo itself, though that constraint applies to contributors, not to applications consuming the published packages. The practical upgrade cost is the migration surface: reducers, effects and selectors written against an older major version may need the codemods in MIGRATION.md rather than a version bump alone.

Where NgRx Is the Wrong Choice

NgRx asks you to learn actions, reducers, selectors, effects and the devtools before the first screen works. For an application with one or two features and no shared state, that is overhead with no payoff, and a service exposing a signal is fewer moving parts. The second failure mode is subtler: teams adopt Store for everything, including state that lives for one component's lifetime, and end up with a global action namespace that is hard to read. Component Store exists in this repository precisely because global state is not always the right scope, and reaching for Store when Component Store fits is a design mistake the library does not prevent. The third case is a team without RxJS fluency. Effects are streams, and debugging a stream you do not understand is worse than debugging an imperative call. NgRx does not remove that prerequisite; it makes it explicit.

NgRx Against Plain Angular Signals and Services

The real alternative is not another library but Angular's own signals and services. A service that holds a signal gives you reactive reads and a single writer without actions, reducers, effects or devtools. The difference in approach is architectural: signals and services centralize state in an object you mutate through methods, while NgRx centralizes it in a reducer you cannot mutate and records every transition as an action. That record is the point. If you need to replay a session, log why state changed, or enforce that only reducers write, NgRx provides the mechanism and a plain signal service does not. If you need a shared counter and a list, the signal service wins on lines of code. The two are not mutually exclusive; a codebase can keep feature-local state in signals and reserve Store for cross-feature state, and the presence of Component Store in this repository suggests the maintainers expect that split.

Licence, Maintenance and What to Check Before Adopting

The LICENSE file sits at the repository root, and package.json declares "license": "MIT", while the repository metadata GitHub returns reports the licence as NOASSERTION, meaning GitHub could not classify the file automatically. Those two signals disagree in presentation only, but a legal review should read the actual LICENSE file rather than the badge. On maintenance, the last push to the default branch was on 2026-09-11, which is recent, and the repository is not archived. The README describes NgRx as community-driven and asks companies to sponsor the libraries, which is a real signal about how the work is funded: sponsorships, not a single vendor's product roadmap. The README does not document a release cadence, a support window for older majors, or a rollback path for a failed upgrade. Before adopting, check the published versions of the specific @ngrx packages you need against your Angular release, and read MIGRATION.md for the major you are moving to.

Editorial conclusion

Adopt NgRx when several Angular feature teams must share one predictable store and you already accept reducer and effect boilerplate as the price of that predictability. Do not adopt it for a small app with a handful of screens, where a service holding signals is less code and fewer concepts. Before committing, verify three things against the version you install: that @ngrx/store and @ngrx/effects publish versions matching your Angular release, that the signal-based APIs you intend to use are documented for that version on ngrx.io, and that the LICENSE file in the repository, which GitHub reports as NOASSERTION while package.json declares MIT, is acceptable to your legal review. The repository was last pushed on 2026-09-11.

Frequently asked questions

Official sources

1. Issues
2. ngrx/platform on GitHub
3. Project website
4. README