# NGXS: state management for Angular without the RxJS homework

> NGXS is an Angular state management library built around stores, actions and selectors, with a stated goal of cutting boilerplate and not requiring deep RxJS knowledge. Here is how it works, how to install it, and where it stops being the right tool.

**ngxs/store** — 🚀 NGXS - State Management for Angular

- Repository: https://github.com/ngxs/store
- Website: http://ngxs.io
- Stars: 3,543 · Forks: 406
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/ngxs-store

## What NGXS solves, and for whom

The README states the goal plainly: NGXS tries to make things as simple and accessible as possible, and a main goal is to reduce boilerplate so you can do more with less. It also says you do not need to be super familiar with RxJS. That second claim is the more interesting one, because it defines who the project is for.

Angular teams that have used a reducer-style store know the shape of the problem. You write action constants, action creators, a reducer switch, effect classes, and selector functions, then wire the whole thing into a module. NGXS keeps the store pattern but changes the unit of work. A state class carries the state and the handlers together. Actions are classes. Selectors are methods decorated on the state class. The README frames the library as a pattern plus a library, not just a package, which is honest: the conventions matter as much as the code.

The audience is Angular application developers, and the topics list (angular, cqrs, event-sourcing, redux, state-management) tells you the mental model it borrows from. If your team already thinks in actions and state transitions, the vocabulary transfers. If your team has never used a store, the README's claim about lower boilerplate is the reason to look, not a guarantee.

## How a store, an action and a selector fit together

The repository layout makes the architecture visible before you read any tutorial. The root package.json lists eight packages under packages/: store, logger-plugin, devtools-plugin, storage-plugin, websocket-plugin, form-plugin, router-plugin and hmr-plugin. The core is @ngxs/store. Everything else is an optional plugin that hooks into the same action pipeline, which is why the README separates Tools (@ngxs/cli, @ngxs/schematics) from Packages.

Data flows in one direction. A component dispatches an action. The store routes that action to the state classes that declared a handler for it. The handler mutates a context object, not the state object directly. Selectors then read slices back out. Because the plugins attach to the same dispatch stream, the logger plugin can print every action and the devtools plugin can record them without the state classes knowing either exists. That is the practical benefit of the plugin split: observability is a registration decision, not a change to your business logic.

The schematics package is the other structural signal. Scaffolding is treated as part of the product rather than an afterthought, and the README links NGXS Schematics for generating the pieces. A library that ships generators is usually a library with enough repeated structure that generating it beats typing it.

One thing the README does not document is rollback or state reversion. There is an hmr-plugin for hot module replacement during development, but the README is silent on undoing a committed action in production. If your requirements include time travel outside a devtools session, verify that yourself before you build on it.

## Installing NGXS and dispatching your first action

The README points to the docs site at ngxs.io and to the schematics page for scaffolding, and the package is published as @ngxs/store on npm. The repository's own install path is Yarn, and the root package.json contains a preinstall guard that throws if you install with npm instead. That guard is for working in the repository itself; consuming the published package is a normal dependency add.

```bash
yarn add @ngxs/store
```

The README does not reproduce the registration and state-class code in the file available here, so the exact snippet for provideStore, the @State decorator and the @Action decorator should be taken from the docs site at ngxs.io rather than reconstructed. What the README does give you is the fastest way to see the wiring end to end: a Stackblitz reproduction at stackblitz.com/edit/ngxs-repro and a sample application in the integration directory of the repository. Open the Stackblitz project first, dispatch an action there, and watch the state change before you write your own state class.

For scaffolding, the README links NGXS Schematics, which generates the pieces rather than asking you to type them. Once a state class exists, the component side is a store service for dispatch and the select decorator for reads, with the value consumed through the async pipe. What you should see is the component re-rendering from the selector rather than from local component state.

## Where NGXS is the wrong choice

The first limitation is structural, not technical: NGXS is state management for Angular. The README describes it as a state management pattern plus library for Angular, and the packages depend on Angular's dependency injection and decorators. If you are building a React or Vue application, nothing here applies. There is no framework-agnostic core to lift out.

The second is the decorator and class model. State is declared with @State and handlers with @Action. That is pleasant inside Angular and awkward outside it, and it also means your state layer is coupled to the compiler configuration that supports decorators. Teams that have moved toward plain functions and signals may find the class-based shape heavier than what they want.

The third is that the plugin ecosystem is where a lot of the useful behaviour lives. Persistence is a separate package, storage-plugin. Debugging integration is devtools-plugin. If you install only @ngxs/store you get the core and nothing else, and the README does not present a batteries-included path. Budget for deciding which of the eight packages you actually need.

Finally, the README's own framing sets an expectation it does not quantify. It says a main goal is to reduce boilerplate and that deep RxJS familiarity is not necessary. Neither claim comes with a measurement in the README. Whether the reduction is meaningful for your codebase is something you will judge from one real feature, not from the description.

## NGXS compared with a reducer-first Angular store

The obvious alternative for an Angular team is a reducer-first store in the Redux tradition, and the repository's own keywords list redux and ngrx alongside ngxs, so the comparison is one the project invites rather than one an outsider is imposing.

The difference is where the code lives. In a reducer-first design, the reducer function is the only place state changes, and side effects are separated into a distinct construct that listens for actions and dispatches new ones. NGXS keeps the action as the trigger but lets the state class own both the state and the handler that changes it, so a feature's state and its transitions sit in one file. That is the boilerplate reduction the README talks about, and it is also the trade-off: co-locating the handler with the state makes it easier to write a handler that does more than transition state, and the separation in a reducer-first design exists to prevent exactly that.

The RxJS point cuts the same way. NGXS uses observables for selection and dispatch, but the README's claim is that you do not need to be fluent in RxJS to use it. A reducer-first store in Angular tends to put more of the effect and stream composition in front of you. If your team is comfortable with operators, that is not a cost. If it is not, NGXS is the lower-friction entry point, at the price of a class-and-decorator model that some teams now avoid.

## Maintenance, versions and the MIT licence

The repository is not archived, and the last push was on 2026-09-12. The release history shows v22.0.0 on 2026-07-01, v21.0.0 on 2025-12-17 and v20.1.0 on 2025-07-16: roughly two major lines per year, with the root package.json at version 22.0.0. That cadence matters for upgrade planning because major versions land on a regular schedule rather than accumulating indefinitely.

The repository is a monorepo managed with Nx, and the root package.json contains a preinstall guard that throws if you install with npm instead of Yarn. That guard applies to developing the repository itself, not to consuming @ngxs/store from npm, and the distinction is worth keeping straight if you plan to send a patch. Contributing is documented separately in CONTRIBUTING.md and a developer guide under docs/.

The licence is MIT, which the README links from the LICENSE file and the package.json repeats. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. That is a description of the terms, not legal advice, and the obligations you actually carry depend on how you distribute your application. If you bundle the library into a product, read the LICENSE file rather than this paragraph.

Upgrade cost is the part the README does not estimate. There is a CHANGELOG.md at the repository root and the README links it for updates, so the migration detail exists, but nothing in the README tells you how large a jump between majors is. Read the changelog entries between your current version and the target before you schedule the work.

## Conclusion

Adopt NGXS if you are on Angular, want the reducer and effect ceremony reduced, and are comfortable modelling state as classes with actions and selectors. Do not adopt it if you are not on Angular, or if you need a state layer that survives a framework change. Before committing, install @ngxs/store, register provideStore in your application providers, define one state class with an action handler, and confirm that the select decorator returns the value you expect in a component.

## FAQ

### What is NGXS used for?

NGXS is a state management pattern and library for Angular, published as @ngxs/store and a set of optional plugins such as logger-plugin, devtools-plugin and storage-plugin. It is used to hold application state in state classes and change it by dispatching actions.

### How do I install NGXS in an Angular project?

The published package is @ngxs/store on npm, and the README links NGXS Schematics for scaffolding the pieces. The repository itself requires Yarn, enforced by a preinstall guard in the root package.json.

### Does NGXS require deep RxJS knowledge?

The README states that it is not necessary to be super familiar with RxJS, and lists reducing boilerplate as a main goal. Selection and dispatch still use observables, so some familiarity helps when reading component code.

### Which packages are part of the NGXS repository?

The root package.json lists store, logger-plugin, devtools-plugin, storage-plugin, websocket-plugin, form-plugin, router-plugin and hmr-plugin under packages/, with @ngxs/cli and @ngxs/schematics listed separately as tools.

### What licence does NGXS use?

The repository and the root package.json both state the MIT licence. MIT permits use, modification and redistribution provided the licence and copyright notice are retained.

## Sources

- [License: MIT](https://github.com/ngxs/store/blob/master/LICENSE)
- [ngxs/store on GitHub](https://github.com/ngxs/store)
- [Project website](http://ngxs.io)
- [README](https://github.com/ngxs/store/blob/master/README.md)
- [Releases](https://github.com/ngxs/store/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ngxs-store