NgRx in Angular: A Practical Guide to State Management, Architecture, and Real-World Patterns

NgRx is more than a store. It is an architecture for managing complex application state in Angular using predictable state transitions, reactive programming, and unidirectional data flow. Modern Angular applications can start simple, but as the application grows, state management becomes increasingly difficult. You may eventually have: Components sharing the same data Multiple API requests updating the same state Complex loading and error states Data that must survive navigation Business logic spread across components Race conditions between asynchronous operations Difficult-to-debug state changes This is where NgRx becomes useful. In this article, we will build the concepts from the ground up and gradually move toward real-world patterns. Table of Contents What Is State Management? Why Do We Need NgRx? What Is NgRx? NgRx Architecture The Unidirectional Data Flow Store Actions Reducers Selectors Effects Dispatching Actions Reading State Complete CRUD Example Async Operations Loading and Error States Entity State NgRx Entity Feature-Based State ComponentStore vs Store Facades Immutability Common NgRx Patterns Common Mistakes Performance Testing When Should You Use NgRx? Final Architecture 1. What Is State Management? Before understanding NgRx, we need to understand state. State is simply the data that describes the current condition of your application. For example: interface User { id: number; name: string; email: string; } Your application might have: interface AppState { user: User | null; isLoading: boolean; error: string | null; } At a particular moment: { user: { id: 1, name: ‘John’, email: ‘john@example.com’ }, isLoading: false, error: null } This is application state. 2. Local State vs Global State Not every piece of state needs NgRx. Consider a button: isMenuOpen = false; This is usually local component state. You probably don’t need a global store for it. But consider: Authentication Products Shopping Cart User Profile Notifications Permissions Orders These may be shared by many parts of the application. For example: Navbar ↓ User Authentication State ↑ Profile Page ↑ Checkout ↑ Orders When many components depend on the same state, centralized state management becomes useful. 3. What Is NgRx? NgRx is a collection of Angular libraries inspired by Redux and built around reactive programming with RxJS. The core idea is: Component ↓ Action ↓ Reducer / Effect ↓ Store ↓ Selector ↓ Component Instead of allowing components to modify shared state directly, state changes happen through actions. This creates predictable state transitions. 4. NgRx Architecture The main pieces are: ┌─────────────┐ │ Component │ └──────┬──────┘ │ dispatch │ ▼ ┌─────────────┐ │ Action │ └──────┬──────┘ │ ┌─────────┴─────────┐ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Reducer │ │ Effect │ └────┬─────┘ └────┬─────┘ │ │ │ ▼ │ HTTP / API │ │ │ ▼ │ Action │ │ └─────────┬─────────┘ ▼ ┌──────────┐ │ Store │ └────┬─────┘ │ select │ ▼ ┌─────────────┐ │ Component │ └─────────────┘ There are five concepts you should understand extremely well: Actions Reducers Store Selectors Effects 5. The Unidirectional Data Flow NgRx follows a unidirectional data flow. That means data moves in a predictable direction. UI ↓ Action ↓ State Transition ↓ Store ↓ Selector ↓ UI For example: this.store.dispatch( increment() ); The component does not directly change: count = count + 1; Instead, it describes what happened: increment() The reducer determines how the state should change. 6. The Store The Store is the centralized state container. Imagine: interface AppState { counter: number; user: User | null; products: Product[]; } Conceptually: Store ├── counter ├── user └── products The Store itself is observable. You read state reactively: counter = this.store.select(selectCounter); Then:

{{ counter | async }}

7. Actions An Action describes something that happened. Example: import { createAction } from ‘@ngrx/store’; export const increment = createAction( ‘[Counter] Increment’ ); Another: export const loadProducts = createAction( ‘[Products Page] Load Products’ ); The string: [Products Page] Load Products is the action type. A good action describes an event. Prefer: [Login Page] Login Submitted over: [Auth] Set User Why? Because the first describes what happened, while the second describes an implementation detail. 8. Actions With Payloads Actions can carry data. export const addToCart = createAction( ‘[Cart] Add Product’, props<{ productId: number }>() ); Dispatch: this.store.dispatch( addToCart({ productId: 10 }) ); Another example: export const login = createAction( ‘[Login Page] Login Submitted’, props<{ email: string; password: string; }>() ); Then: this.store.dispatch( login({ email: ‘john@example.com’, password: ‘123456’ }) ); 9. Reducers Reducers determine how state changes in response to actions. Example: import { createReducer, on } from ‘@ngrx/store’; export const initialState = 0; export const counterReducer = createReducer( initialState, on(increment, state => state + 1) ); The important concept is: Action + Current State ↓ New State For example: State = 5 Action = increment Reducer 5 + 1 New State = 6 10. Reducers Must Be Pure A reducer should be: Predictable Synchronous Pure Free from side effects Don’t do this inside a reducer: on(loadProducts, state => { http.get(‘/products’); return state; }); Reducers should not perform HTTP requests. They should only calculate the next state. 11. Immutable State NgRx relies heavily on immutability. Bad: state.user.name = ‘John’; return state; Good: return { …state, user: { …state.user, name: ‘John’ } }; The idea is to create a new state reference instead of mutating the existing one. 12. Selectors Selectors are used to read data from the Store. Suppose: interface CounterState { count: number; } Create a feature selector: export const selectCounterState = createFeatureSelector(‘counter’); Then: export const selectCount = createSelector( selectCounterState, state => state.count ); Component: count = this.store.select(selectCount); Template:

{{ count | async }}

13. Why Selectors Are Important You might ask: Why not simply get the entire state? Because selectors provide: Encapsulation Components don’t need to know how state is structured. Memoization Selectors can avoid unnecessary recalculations. Reusability Multiple components can use the same selector. Performance Components subscribe only to the data they need. 14. Derived State One of the most powerful selector features is derived state. Suppose: interface CartState { items: CartItem[]; } You can calculate: export const selectCartTotal = createSelector( selectCartItems, items => items.reduce( (total, item) => total + item.price * item.quantity, 0 ) ); The total does not need to be stored separately. Instead: Cart Items ↓ Selector ↓ Cart Total This avoids duplicated state. 15. Effects Effects handle side effects. Examples: HTTP Requests Local Storage Analytics Navigation WebSocket interactions External APIs Suppose: User clicks Load Products ↓ loadProducts action ↓ Effect ↓ HTTP request ↓ API response ↓ loadProductsSuccess ↓ Reducer ↓ Store This is the main purpose of NgRx Effects. 16. Example Effect @Injectable() export class ProductsEffects { loadProducts = createEffect(() => this.actions.pipe( ofType(loadProducts), switchMap(() => this.productsService.getProducts().pipe( map(products => loadProductsSuccess({ products }) ), catchError(error => of(loadProductsFailure({ error })) ) ) ) ) ); constructor( private actions: Actions, private productsService: ProductsService ) {} } The effect listens for: loadProducts Then performs: productsService.getProducts() And dispatches: loadProductsSuccess or: loadProductsFailure 17. The Complete Request Flow Let’s visualize it: User │ ▼ Products Component │ │ dispatch() ▼ loadProducts │ ▼ Products Effect │ │ HTTP ▼ Backend API │ ▼ Response │ ▼ loadProductsSuccess │ ▼ Products Reducer │ ▼ Store │ ▼ selectProducts │ ▼ Products Component This is one of the most important NgRx flows to understand. 18. Loading and Error State A realistic application needs more than data. For example: interface ProductsState { products: Product[]; loading: boolean; error: string | null; } Initial state: const initialState: ProductsState = { products: [], loading: false, error: null }; When loading starts: on(loadProducts, state => ({ …state, loading: true, error: null })) Success: on(loadProductsSuccess, (state, { products }) => ({ …state, products, loading: false })) Failure: on(loadProductsFailure, (state, { error }) => ({ …state, loading: false, error })) 19. Complete Products Example Actions export const loadProducts = createAction( ‘[Products Page] Load Products’ ); export const loadProductsSuccess = createAction( ‘[Products API] Load Products Success’, props<{ products: Product[] }>() ); export const loadProductsFailure = createAction( ‘[Products API] Load Products Failure’, props<{ error: string }>() ); Reducer export interface ProductsState { products: Product[]; loading: boolean; error: string | null; } export const initialState: ProductsState = { products: [], loading: false, error: null }; export const productsReducer = createReducer( initialState, on(loadProducts, state => ({ …state, loading: true, error: null })), on(loadProductsSuccess, (state, { products }) => ({ …state, products, loading: false })), on(loadProductsFailure, (state, { error }) => ({ …state, loading: false, error })) ); Selectors export const selectProductsState = createFeatureSelector(‘products’); export const selectProducts = createSelector( selectProductsState, state => state.products ); export const selectLoading = createSelector( selectProductsState, state => state.loading ); export const selectError = createSelector( selectProductsState, state => state.error ); Component products = this.store.select(selectProducts); loading = this.store.select(selectLoading); error = this.store.select(selectError); loadProducts() { this.store.dispatch(loadProducts()); } Template <button (click)=“loadProducts()”> Load Products @if (loading | async) {

Loading…

} @if (error | async; as error) {

{{ error }}

} @for (product of products | async; track product.id) {

{{ product.name }}

{{ product.price }}

} 20. NgRx Entity Imagine you have: Product[] with thousands of products. You frequently need: Find product by ID Add product Remove product Update product Select all products Managing arrays manually becomes repetitive. NgRx Entity provides utilities for normalized collections. Conceptually: Entity State ids: [1, 2, 3] entities: { 1: Product, 2: Product, 3: Product } Instead of: products.find(p => p.id === id); the entity adapter can provide selectors and operations for you. 21. Entity Adapter Example: const adapter = createEntityAdapter(); Initial state: const initialState = adapter.getInitialState({ loading: false, error: null }); Add products: adapter.addMany(products, state); Update: adapter.updateOne( { id: product.id, changes: product }, state ); Remove: adapter.removeOne(productId, state); This becomes extremely useful for large collections. 22. Feature-Based Architecture A large Angular application should not have one giant Store file. Instead: src/app/ │ ├── core/ │ ├── shared/ │ └── features/ │ ├── auth/ │ ├── store/ │ │ ├── auth.actions.ts │ │ ├── auth.reducer.ts │ │ ├── auth.effects.ts │ │ └── auth.selectors.ts │ │ │ └── pages/ │ ├── products/ │ ├── store/ │ │ ├── products.actions.ts │ │ ├── products.reducer.ts │ │ ├── products.effects.ts │ │ └── products.selectors.ts │ └── cart/ ├── store/ │ ├── cart.actions.ts │ ├── cart.reducer.ts │ ├── cart.effects.ts │ └── cart.selectors.ts This keeps features isolated. 23. NgRx Facade Pattern Some teams don’t want components to know about NgRx directly. Instead, introduce a facade. @Injectable({ providedIn: ‘root’ }) export class ProductsFacade { products = this.store.select(selectProducts); loading = this.store.select(selectLoading); constructor( private store: Store ) {} loadProducts() { this.store.dispatch(loadProducts()); } } Component: constructor( private productsFacade: ProductsFacade ) {} products = this.productsFacade.products; loadProducts() { this.productsFacade.loadProducts(); } Now the component doesn’t know about: Actions Selectors Store It only knows: ProductsFacade This can be useful in large applications. 24. RxJS and NgRx NgRx relies heavily on RxJS. For example: this.store.select(selectProducts) returns an Observable. Effects also use RxJS operators: ofType() switchMap() mergeMap() concatMap() exhaustMap() map() catchError() Understanding RxJS is therefore extremely valuable when working with NgRx. 25. Choosing the Correct Flattening Operator This is a common interview topic. switchMap Cancels the previous request. Useful for: Search Autocomplete Example: actions.pipe( ofType(searchProducts), switchMap(…) ); concatMap Queues requests. Request 1 ↓ Request 2 ↓ Request 3 Useful when order matters. mergeMap Runs requests concurrently. Request 1 ────────┐ Request 2 ────────┤ Request 3 ────────┘ Useful when requests are independent. exhaustMap Ignores new requests while one is running. Useful for: Login Submit button Payment For example: actions.pipe( ofType(login), exhaustMap(…) ); If the user clicks Login multiple times quickly, subsequent clicks are ignored until the first request completes. 26. NgRx vs Services You don’t need NgRx for every Angular application. A simple service may be enough: @Injectable({ providedIn: ‘root’ }) export class CartService { private cartSubject = new BehaviorSubject<CartItem[]>([]); cart = this.cartSubject.asObservable(); add(item: CartItem) { const current = this.cartSubject.value; this.cartSubject.next([ …current, item ]); } } This can work perfectly well for a small application. NgRx becomes more valuable when state transitions and interactions become complex. 27. NgRx vs ComponentStore NgRx Store is designed for centralized application state. ComponentStore is better suited for localized state. Example: Global Application State ↓ Store Feature-local state ↓ ComponentStore You don’t necessarily need to choose one exclusively. A large application can use both. 28. What Should NOT Go Into NgRx? A common mistake is putting everything into the Store. Don’t automatically store: isDropdownOpen hoveredItem temporary input values modal visibility simple UI flags unless there is a real reason. Ask: Does this state need to be shared, persisted, coordinated, or observed across multiple parts of the application? If not, local state may be better. 29. Avoid Duplicated State Suppose you have: products: Product[]; selectedProduct: Product; You may be duplicating information. Instead, consider: products: Product[]; selectedProductId: number | null; Then: export const selectSelectedProduct = createSelector( selectProducts, selectSelectedProductId, (products, id) => products.find(product => product.id === id) ?? null ); Now there is one source of truth. 30. Keep Business Logic Out of Components Bad: loadProducts() { this.loading = true; this.http.get(‘/products’) .subscribe(products => { this.products = products; this.loading = false; }); } This mixes: UI HTTP State Loading Error handling With NgRx: loadProducts() { this.store.dispatch(loadProducts()); } The component becomes much simpler. 31. Smart vs Presentational Components NgRx works well with the separation between container and presentational components. Container Responsible for state interaction. products = this.facade.products; Presentational Receives data: @Input() products: Product[] = []; and emits events: @Output() productSelected = new EventEmitter(); Architecture: Container │ ├── Store │ └── Presentational Component │ └── UI 32. Router Store NgRx can also integrate router state. This can allow application state to react to route changes. Conceptually: URL ↓ Router ↓ Router Store ↓ Selectors ↓ Application This can be useful when route parameters influence application state. 33. DevTools One of the major advantages of NgRx is debugging. With Redux DevTools, you can inspect: Action ↓ Previous State ↓ Next State For example: [Cart] Add Product Previous: items: [] Next: items: [Product 1] This makes complex state transitions much easier to understand. 34. Time-Travel Debugging Because state changes are represented as actions, you can conceptually replay state transitions. Action 1 Action 2 Action 3 Action 4 Instead of debugging: “Something changed somewhere.” you can investigate: “Which action caused the state transition?” This is one of the architectural strengths of Redux-style state management. 35. Testing Reducers Reducers are easy to test because they are pure functions. Example: it(‘should increment counter’, () => { const state = counterReducer( 5, increment() ); expect(state).toBe(6); }); No HTTP request. No browser. No asynchronous operation. Just: Input ↓ Reducer ↓ Output 36. Testing Selectors Selectors can also be tested independently. For example: const state = { products: [ { id: 1, price: 100 }, { id: 2, price: 200 } ] }; Then verify: expect(selectProducts.projector( state.products )).toEqual(state.products); Selectors are another reason to keep business calculations outside components. 37. Testing Effects Effects require testing asynchronous behavior. Conceptually: Input Action ↓ Effect ↓ Mock API ↓ Output Action You can verify: loadProducts ↓ API called ↓ loadProductsSuccess or: loadProducts ↓ API error ↓ loadProductsFailure 38. Common NgRx Mistakes Mistake 1 — Putting everything in Store Not every variable belongs in global state. Mistake 2 — Mutating state Bad: state.products.push(product); return state; Good: return { …state, products: [ …state.products, product ] }; Mistake 3 — HTTP inside reducers Never. Use Effects or another appropriate side-effect mechanism. Mistake 4 — Huge selectors Selectors should remain focused and composable. Mistake 5 — Components containing business logic If your component becomes: 500+ lines and heavily interacts with Store, consider extracting logic. Mistake 6 — Overusing Effects Effects are for side effects. Don’t create an effect just to transform simple state synchronously when a reducer or selector is enough. 39. NgRx and Angular Signals Modern Angular applications increasingly use Signals. You can bridge Store Observables into Signals. For example: products = this.store.selectSignal(selectProducts); Then in the template: @for (product of products(); track product.id) {

{{ product.name }}

} This gives you a more signal-oriented component API while still using NgRx for centralized state management. 40. A Real-World E-Commerce Architecture Imagine an e-commerce application. We could structure the state as: Application Store │ ├── Auth │ ├── user │ ├── token │ └── loading │ ├── Products │ ├── entities │ ├── filters │ ├── loading │ └── error │ ├── Cart │ ├── items │ └── total │ ├── Orders │ ├── entities │ ├── loading │ └── error │ └── UI ├── notifications └── theme The flow could be: User │ ▼ Angular Component │ ▼ Action │ ├──────────────┐ ▼ ▼ Reducer Effect │ │ ▼ ▼ Store API │ │ │ ▼ │ Success Action │ │ └──────────────┘ │ ▼ Selector │ ▼ Component This architecture scales significantly better than putting all application logic into components. 41. When Should You Use NgRx? NgRx is a good choice when your application has: Complex shared state Multiple features depending on the same data Many asynchronous workflows Complex state transitions Large teams Strong debugging requirements Event-driven architecture Need for predictable state changes Significant business logic Examples: E-commerce Banking dashboards Admin platforms CRM systems Large SaaS applications Enterprise applications Real-time applications 42. When Should You Avoid NgRx? For a small application: 5 components 2 API calls simple forms little shared state NgRx may introduce unnecessary complexity. A simple: Component ↓ Service ↓ HTTP architecture might be better. The goal is not: “Use NgRx because NgRx is powerful.” The goal is: “Use the simplest architecture that can reliably manage the application’s complexity.” 43. The Most Important Mental Model If you remember only one thing, remember this: Action = What happened? Reducer = How does state change? Effect = What side effect should happen? Selector = What state does the UI need? Store = Where is application state centralized? For example: User clicks “Add to Cart” Action: [Product Page] Add To Cart ↓ Reducer: Add product to cart state ↓ Effect: Maybe synchronize cart with backend ↓ Store: Updated cart ↓ Selector: Calculate cart count ↓ UI: Cart: 3 items That is NgRx. 44. Final Architecture A mature Angular + NgRx application can look like: Angular UI │ ▼ Component / Facade │ ▼ Action │ ┌──────────┴──────────┐ │ │ ▼ ▼ Reducer Effect │ │ │ HTTP/API │ │ │ ▼ │ Success/Failure │ │ └──────────┬──────────┘ ▼ Store │ ▼ Selectors │ ▼ Component / UI This architecture gives you: Predictable state transitions Centralized state Reactive data flow Testable business logic Clear separation of concerns Better debugging Scalable feature architecture Conclusion NgRx is not simply a library for storing variables. It is a state-management architecture built around a very clear philosophy: Events ↓ Actions ↓ State Transitions ↓ Store ↓ Selectors ↓ UI Effects extend this architecture by handling asynchronous operations and other side effects. The real power of NgRx appears when an application becomes complex enough that managing state manually starts becoming difficult. The key is not to memorize APIs. Understand the architecture first: Actions Reducers Selectors Effects Store Once those concepts are clear, the NgRx APIs become much easier to learn. And the most important practical rule is: Don’t introduce NgRx because your application is Angular. Introduce it because your application’s state management has become complex enough to justify it.

View original article