Frontend interview answer

NgRx data flow end-to-end in Angular: actions, reducers, effects, selectors

HighIntermediateAngular

By FrontendAtlas Editorial · Updated Apr 10, 2026

Interview quick answer

NgRx data flow in Angular is a 5-step, DevTools-traceable loop: component action dispatch, immutable reducer state diff, effect success/failure result, selector VM, and template loading/data/error/retry UI.

Interview focus

This Angular interview question tests whether you can explain NgRx Data Flow in Angular: From Action to Retry UI, connect it to production trade-offs, and handle common follow-up questions.

NgRx Data Flow in Angular: From Action to Retry UI explanation without falling back to memorized definitions
Store and Selectors reasoning, edge cases, and production failure modes
How you would answer the most likely Angular interview follow-up

Practice more Angular interview questions

Interview answer drill

Use this Angular interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice more Angular interview questions Follow 30-day foundations study plan Open Essential 60

Full interview answer

Operational loop

NgRx is most useful when you explain it as a debuggable one-way loop that matches a DevTools trace: component action dispatch, immutable reducer state diff, effect success/failure result, selector VM, and template loading/data/error/retry UI. That 5-step framing is what separates memorized terms from production understanding.

Step	Who does it	What happens	Why it matters
UI intent	Component	User clicks/searches; component dispatches an action	Events become explicit and traceable
State transition	Reducer	Pure function returns next immutable state	Predictable updates and easy debugging
Async side effect	Effect	Listens to action, calls API, dispatches success/failure	Keeps reducers pure and components thin
Read model	Selector	Memoized selection/derivation from store state	Performance + reusable view logic
Render	Template + async pipe	Subscribes to selector output and updates UI	Reactive view with minimal manual subscriptions

NgRx data flow diagram (end-to-end loop)

TYPESCRIPT

// books.actions.ts
import { createAction, props } from '@ngrx/store';

export const loadBooks = createAction('[Books Page] Load Books');
export const loadBooksSuccess = createAction(
  '[Books API] Load Books Success',
  props<{ books: Book[] }>()
);
export const loadBooksFailure = createAction(
  '[Books API] Load Books Failure',
  props<{ error: string }>()
);

TYPESCRIPT

// books.reducer.ts
import { createReducer, on } from '@ngrx/store';

export interface BooksState {
  books: Book[];
  loading: boolean;
  error: string | null;
}

export const initialState: BooksState = {
  books: [],
  loading: false,
  error: null
};

export const booksReducer = createReducer(
  initialState,
  on(loadBooks, state => ({ ...state, loading: true, error: null })),
  on(loadBooksSuccess, (state, { books }) => ({ ...state, books, loading: false })),
  on(loadBooksFailure, (state, { error }) => ({ ...state, error, loading: false }))
);

TYPESCRIPT

// books.effects.ts
import { Injectable, inject } from '@angular/core';
import { Actions, createEffect, ofType } from '@ngrx/effects';
import { catchError, map, of, switchMap } from 'rxjs';

@Injectable()
export class BooksEffects {
  private actions$ = inject(Actions);
  private api = inject(BooksApiService);

  loadBooks$ = createEffect(() =>
    this.actions$.pipe(
      ofType(loadBooks),
      switchMap(() =>
        this.api.getBooks().pipe(
          map(books => loadBooksSuccess({ books })),
          catchError(err => of(loadBooksFailure({ error: String(err) })))
        )
      )
    )
  );
}

TYPESCRIPT

// books.selectors.ts
import { createFeatureSelector, createSelector } from '@ngrx/store';

export const selectBooksState = createFeatureSelector<BooksState>('books');
export const selectBooks = createSelector(selectBooksState, s => s.books);
export const selectLoading = createSelector(selectBooksState, s => s.loading);
export const selectError = createSelector(selectBooksState, s => s.error);
export const selectVm = createSelector(
  selectBooks,
  selectLoading,
  selectError,
  (books, loading, error) => ({
    books,
    loading,
    error,
    total: books.length,
    canRetry: Boolean(error)
  })
);

TYPESCRIPT

// books-page.component.ts
import { ChangeDetectionStrategy, Component, inject } from '@angular/core';
import { Store } from '@ngrx/store';

@Component({
  selector: 'app-books-page',
  template: `
    <button (click)="reload()">Reload</button>

    <ng-container *ngIf="vm$ | async as vm">
      <p *ngIf="vm.loading">Loading...</p>
      <p *ngIf="vm.error">Error: {{ vm.error }}</p>
      <button *ngIf="vm.canRetry" (click)="reload()">Try again</button>
      <p>Total: {{ vm.total }}</p>
      <li *ngFor="let b of vm.books">{{ b.title }}</li>
    </ng-container>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class BooksPageComponent {
  private store = inject(Store);
  readonly vm$ = this.store.select(selectVm);

  ngOnInit(): void {
    this.store.dispatch(loadBooks());
  }

  reload(): void {
    this.store.dispatch(loadBooks());
  }
}

Common mistake	Why it breaks	Fix
Putting HTTP in reducers	Reducers must be synchronous and pure	Move async work to effects
Doing heavy mapping in components	Duplicates logic and hurts performance	Use memoized selectors for derived view models
Subscribing manually everywhere	Leak risk and boilerplate	Use `store.select(...)` + `async` pipe
Dispatching vague action names	Hard to trace intent in DevTools	Use event-style action naming (`[Source] Event`)

What interviewers flag quickly

Pure reducer update vs effect-driven async update

A quick way to explain NgRx clearly is to separate the sync transition from the async side effect. Reducers update flags synchronously. Effects handle API work and feed the result back into the store.

TYPESCRIPT

// reducer: synchronous state transition
on(loadBooks, state => ({ ...state, loading: true, error: null }))

// effect: async work beside the reducer loop
loadBooks$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadBooks),
    switchMap(() => this.api.getBooks().pipe(
      map((books) => loadBooksSuccess({ books })),
      catchError((error) => of(loadBooksFailure({ error: String(error) })))
    ))
  )
);

Compact trace you should be able to say out loud

Load Books click -> loadBooks action -> reducer sets loading=true -> effect calls API -> loadBooksSuccess/loadBooksFailure -> reducer stores result -> selector builds vm -> template re-renders. That trace is useful because each step can be checked against a DevTools action log, reducer state diff, effect result, selector output, and template state.

Selectors are memoized read models

A selector is not just a getter. It is the read layer that turns raw store state into a reusable, memoized view model so components do not keep sorting, filtering, and combining the same data in multiple places.

When this loop is worth the ceremony

Use NgRx when the state is shared, long-lived, business-critical, written by multiple workflows, or needs replayable debugging. Keep short-lived local UI details close to the component when no other screen depends on them.

State pressure	Use NgRx when	Keep local when
Shared ownership	Multiple routes, panels, or teams depend on the same entity state	One component owns the state and can reset it on destroy
Async workflow	Loading, success, failure, retry, optimistic update, or WebSocket events need a trace	A single request updates one local view without cross-feature coordination
Debug/audit need	You need action history, state diffs, and repeatable transitions	The state is a local toggle, hover, tab, drawer, or temporary form detail

NgRx ceremony decision check

Store state vs selector view model

The store should hold the durable source of truth. Selectors should shape that truth into the exact read model the component needs. Components should render the selector contract instead of rebuilding state shape locally.

Layer	Owns	Avoid
Store state	Raw/domain state such as ids, entities, loading, and error	Storing filtered or sorted UI-only copies as global truth
Selector view model	Derived data such as visible books, total count, empty state, and retry visibility	Recomputing the same filter/sort/map work in every component
Component template	Rendering `vm$ \| async` and dispatching user intent	Manual subscriptions, hidden mutations, or service calls that bypass the loop

Store truth vs selector read model

Where this plugs into Angular

The loop only works once the feature state and effects are registered at the Angular boundary. In a standalone Angular app, keep that setup near the feature route or app config so the reducer owns state transitions and the effect owns async workflows.

TYPESCRIPT

// books.routes.ts or app.config.ts
import { provideEffects } from '@ngrx/effects';
import { provideState } from '@ngrx/store';

export const booksFeatureProviders = [
  provideState('books', booksReducer),
  provideEffects(BooksEffects)
];

Debugging an NgRx loop in DevTools

A production-quality explanation should map each step to a debugging signal. If the action log, state diff, effect result, selector output, and template state tell the same story, the loop is healthy.

Debug point	What to inspect	Bad signal
Action log	`loadBooks`, then `loadBooksSuccess` or `loadBooksFailure`	No action appears, or vague action names hide the source
State diff	`loading`, `books`, and `error` change immutably	Reducer mutates state or writes async data before the effect returns
Selector output	`selectVm` exposes the exact render model	Component rebuilds filtered arrays or misses loading/error branches
Template render	Async pipe renders loading, data, empty, error, and retry states	Manual subscriptions leak or stale UI stays visible after failure

NgRx DevTools debugging trace

Failure path and retry UI trace

The failure path is where the architecture usually proves itself. The effect dispatches a failure action, the reducer records the error, the selector exposes retry state, and the retry button dispatches the same load intent again.

Step	State/action	UI result
API fails	Effect maps the error to `loadBooksFailure({ error })`	Reducer clears loading and stores a readable error
Selector builds VM	`{ books, loading: false, error, canRetry: true }`	Template shows the error and retry action without extra component mapping
User retries	Retry button dispatches `loadBooks()`	The same loop restarts instead of calling the API directly from the template

Failure action to retry UI trace

Interactive DevTools trace visual

Use the interactive trace below to inspect the same loop as a DevTools-style proof: action log, reducer state diff, effect result, selector VM, template state, and the retry path after loadBooksFailure.

Testable proof

A focused reducer and selector test should prove the failure path without bootstrapping Angular. After loadBooksFailure, the reducer should clear loading, store the error, and let the selector expose a retry-capable view model.

TYPESCRIPT

it('exposes retry state after load failure', () => {
  const failedState = booksReducer(
    { books: [], loading: true, error: null },
    loadBooksFailure({ error: 'Network error' })
  );

  expect(failedState).toEqual({
    books: [],
    loading: false,
    error: 'Network error'
  });

  expect(selectVm.projector([], false, 'Network error')).toEqual({
    books: [],
    loading: false,
    error: 'Network error',
    total: 0,
    canRetry: true
  });
});

FrontendAtlas review note

When we review an NgRx data-flow answer, we look for concrete boundaries: reducers stay pure, effects own async work, selectors expose the component view model, and the failure/retry path is visible in the same loop. A common failure mode is naming actions and selectors correctly while still hiding API calls, mapping, or retry state inside the component.

Source check

Compare this answer with the NgRx Actions guide, Reducers guide, Effects guide, and Selectors guide. FrontendAtlas content is maintained under the Editorial Policy, with corrections handled through the page issue flow.

Interview summary

In Angular state management with NgRx, components dispatch actions for user intent, reducers compute next immutable state, effects handle async side effects, selectors expose memoized read models, and templates render selector output. If you can explain that loop clearly, you understand NgRx data flow.

NgRx DevTools trace

Action log[Books Page] Load Books

Named user/API event entering the store loop.

State + effectReducer diff

loading: false -> true; error: null

Selector + templateView contract

{ books: [], loading: true, error: null, canRetry: false }

Action log

[Books Page] Load Books

Reducer state diff

loading: false -> true; error: null

Effect result

Effect receives loadBooks and starts BooksApiService.getBooks().

Selector VM

{ books: [], loading: true, error: null, canRetry: false }

Template state

Loading message renders while the list stays owned by selector output.

Proof signal

The user intent appears first as a named action, not as a hidden service call.