Angular 17+ state. The decision that matters first: do you actually need
NgRx, or a signal store? Adding NgRx to state that didn't need it is the
most common Angular over-engineering.

THE TEST
  Shared across many unrelated components + complex async flows + you
  need time-travel/devtools → NgRx.
  Mostly local or simple shared state → signals + a service. Don't reach
  for the store.

IF IT'S NgRx — the standalone, modern setup
  provideStore() in app.config.ts (standalone — no NgModule)
  Feature state with createFeature + createReducer
  Effects for the async: createEffect handling the API calls, so
  components dispatch and read, never fetch.
  Selectors memoized, so the template re-renders only on real change.

IF IT'S SIGNALS — the lighter path
  A signal-based store service: signal() for state, computed() for
  derived values, exposed as readonly. No actions, no reducers, no
  boilerplate — and it integrates with the template's change detection
  natively.

THE RxJS RULE EITHER WAY
Async stays in effects or the service, never in components. A component
that subscribes directly leaks and re-fetches; one that reads a signal
or selector doesn't.

PERFORMANCE
OnPush change detection everywhere, and signals or memoized selectors
so a change to one slice doesn't re-render the tree.

Tell me how much of your state is genuinely shared vs. local, and I'll
tell you which of the two to build — and scaffold it.