In NGXS, how do you define a state slice with @State, change it from an @Action handler, and register it in a standalone Angular app?

## The three pieces NGXS asks you to write NGXS is a state-management library for Angular that models each **slice** of application state as a **class** instead of a reducer function. Three pieces work together: - **The state class** holds the metadata for one slice: its name, its default value and the methods that change it. - **The action class** describes something that happened, such as a guest picking a room. It is a plain TypeScript class with a `static readonly type` string and, optionally, constructor fields for its payload. - **The action handler** is a method on the state class decorated with `@Action(...)`. NGXS calls it when a matching action is dispatched. There is no `switch` over action types and no separate reducer file; NGXS keeps a registry from each action's `type` string to the handlers that declared it. ## Declaring the state ```ts export interface RoomsStateModel { rooms: Room[]; selectedRoomId: string | null; } @State<RoomsStateModel>({ name: 'rooms', defaults: { rooms: [], selectedRoomId: null } }) @Injectable() export class RoomsState {} ``` The options on `@State` are: - **`name`** (required): the key under which this slice lives in the single global state object. It must be unique across the application and safe as an object property name, so no dashes or dots. A `StateToken` can replace the string to give the name a type. - **`defaults`**: the initial value of the slice. - **`children`**: the old way to nest sub-states. It is **deprecated** and should not appear in new code. The class also carries `@Injectable()`. NGXS creates state classes through Angular's dependency injection, so a state can inject an `HttpClient` or a domain service in its constructor or with `inject()`. In development NGXS warns when a state class is not decorated with `@Injectable()` right after `@State()`. ## Writing an action handler ```ts export class SelectRoom { static readonly type = '[Rooms Page] Select Room'; constructor(public roomId: string) {} } // inside RoomsState @Action(SelectRoom) selectRoom(ctx: StateContext<RoomsStateModel>, action: SelectRoom) { ctx.patchState({ selectedRoomId: action.roomId }); } ``` The first argument, `StateContext<T>`, is scoped to this state's slice only: | Member | What it does | |---|---| | `getState()` | Returns the freshest value of this slice each time it is called | | `setState(value)` | Replaces the whole slice; also accepts a state operator | | `patchState(partial)` | Shallow-merges the given top-level properties into the slice | | `dispatch(action)` | Dispatches further actions and returns an Observable | | `abortSignal` | An `AbortSignal` for cancelling async work (NGXS 21 and later) | The handler does **not** return the new state the way a reducer does. It writes through the context. A return value matters only for async work: returning an Observable or a Promise tells NGXS to wait for it before the action counts as complete. One action can be handled by **several states**. A `CheckOutGuest` action can free a room in `RoomsState` and close a booking in `ReservationsState`; each handler gets a context for its own slice. ## Registering and dispatching in a standalone app NGXS 22 follows Angular 22 and is built around standalone providers: 1. In `app.config.ts`, add `provideStore([RoomsState])` to the application providers. An optional second argument takes options such as `developmentMode`, followed by plugin features such as `withNgxsReduxDevtoolsPlugin()`. 2. For states that belong to a lazily loaded route, add `provideStates([ReservationsState])` to that route's `providers`. `provideStore` must still be present at the root. 3. In a component, create a dispatcher with `private selectRoom = dispatch(SelectRoom);` and call `this.selectRoom(id)`, or inject `Store` and call `store.dispatch(new SelectRoom(id))`. `NgxsModule.forRoot()` and `NgxsModule.forFeature()` are still exported, but both are marked **deprecated** in favour of `provideStore()` and `provideStates()`. ## Mistakes interviewers listen for - Writing NGXS actions with NgRx's `createAction` and `props`. NGXS actions are classes with a static `type`. - Returning a new state object from an `@Action` method and expecting NGXS to store it. - Assuming `getState()` returns the whole application state; it returns this slice only. - Believing state classes cannot use services. They are built by DI and can inject them. - Describing `NgxsModule.forRoot` as the current setup in an NGXS 22 codebase. - Reusing one `type` string for two action classes. NGXS matches handlers by the string, not by the class, so the two actions would trigger each other's handlers. By convention the string names its source in brackets, as in `[Rooms Page] Select Room`, which keeps it unique and readable in DevTools.