NGXS框架中API数据持久化与读取的调用位置咨询

Great question—this is one of the most common sticking points when first learning NGXS, especially since many examples use mock data or skip the API layer entirely. Let’s walk through the most clean, maintainable ways to handle your POST (and other) API calls for data persistence, using your "AddItem" scenario as an example.

1. Directly in the Action Handler (State Class) #

This is the most straightforward approach, perfect for simpler use cases where you want to keep action logic tightly coupled with state updates. The idea is: when the AddItem action is dispatched, your state class first calls the backend API to persist the data, then updates the state only if the API call succeeds.

Here’s how that looks in code:

import { State, Action, StateContext, Selector } from '@ngxs/store';
import { HttpClient } from '@angular/common/http';
import { AddItem, AddItemFailed } from './project.actions';

export interface ProjectStateModel {
  projects: Project[];
  error?: string;
}

@State<ProjectStateModel>({
  name: 'projects',
  defaults: {
    projects: [],
    error: undefined
  }
})
@Injectable()
export class ProjectState {
  @Selector()
  static getProjects(state: ProjectStateModel) {
    return state.projects;
  }

  constructor(private http: HttpClient) {}

  @Action(AddItem)
  async handleAddItem(ctx: StateContext<ProjectStateModel>, action: AddItem) {
    try {
      // First, call your POST API to persist the new item
      const persistedProject = await this.http.post<Project>(
        '/api/projects',
        action.payload
      ).toPromise();

      // Only update the state once the API confirms success
      const currentState = ctx.getState();
      ctx.setState({
        ...currentState,
        projects: [...currentState.projects, persistedProject],
        error: undefined // Clear any previous errors
      });
    } catch (error) {
      // Handle failures by updating the error state or dispatching a failure action
      ctx.setState({
        ...ctx.getState(),
        error: 'Failed to add project'
      });
      // Optional: Dispatch a dedicated failure action for more complex error handling
      ctx.dispatch(new AddItemFailed(error));
    }
  }
}

Why this works: It keeps all logic related to the AddItem action contained in one place, ensuring your local state only updates when the backend has successfully persisted the data (avoiding mismatches between client and server).

2. Using NGXS Effects (Separation of Concerns) #

If you prefer to decouple API calls (side effects) from state update logic, NGXS Effects are the way to go. Effects let you listen for actions, run asynchronous logic (like API calls), and then dispatch new actions to trigger state updates.

Here’s an example of this pattern:

Step 1: Create an Effects Class #

import { Injectable } from '@angular/core';
import { Actions, ofActionDispatched, createEffect } from '@ngxs/effects';
import { HttpClient } from '@angular/common/http';
import { AddItem, AddItemSuccess, AddItemFailed } from './project.actions';
import { switchMap, map, catchError } from 'rxjs/operators';
import { of } from 'rxjs';

@Injectable()
export class ProjectEffects {
  constructor(private actions$: Actions, private http: HttpClient) {}

  addProject$ = createEffect(() =>
    this.actions$.pipe(
      ofActionDispatched(AddItem),
      switchMap((action: AddItem) => 
        this.http.post<Project>('/api/projects', action.payload).pipe(
          map(persistedProject => new AddItemSuccess(persistedProject)),
          catchError(error => of(new AddItemFailed(error)))
        )
      )
    )
  );
}

Step 2: Update State from Success/Failure Actions #

// Inside your ProjectState class
@Action(AddItemSuccess)
handleAddItemSuccess(ctx: StateContext<ProjectStateModel>, action: AddItemSuccess) {
  const currentState = ctx.getState();
  ctx.setState({
    ...currentState,
    projects: [...currentState.projects, action.payload],
    error: undefined
  });
}

@Action(AddItemFailed)
handleAddItemFailed(ctx: StateContext<ProjectStateModel>, action: AddItemFailed) {
  ctx.setState({
    ...ctx.getState(),
    error: `Failed to add project: ${action.payload.message}`
  });
}

Why this works: It separates side effects (API calls) from state mutation logic, making both easier to test and maintain. This is ideal for complex applications where you need to handle things like retries, debouncing, or chaining multiple API calls.

3. In a Reusable Service (With Action Dispatches) #

If you need to reuse API logic across multiple components or services, you can encapsulate API calls in a dedicated service, then dispatch actions from the service to update the state.

Example:

Project Service #

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Store } from '@ngxs/store';
import { AddItemSuccess, AddItemFailed } from './project.actions';
import { Project } from './project.model';

@Injectable()
export class ProjectService {
  constructor(private http: HttpClient, private store: Store) {}

  async addProject(project: Project): Promise<void> {
    try {
      const persistedProject = await this.http.post<Project>('/api/projects', project).toPromise();
      this.store.dispatch(new AddItemSuccess(persistedProject));
    } catch (error) {
      this.store.dispatch(new AddItemFailed(error));
    }
  }
}

Component Usage #

import { Component } from '@angular/core';
import { ProjectService } from './project.service';
import { Project } from './project.model';

@Component({
  selector: 'app-project-form',
  template: `...`
})
export class ProjectFormComponent {
  constructor(private projectService: ProjectService) {}

  onSubmit(newProject: Project) {
    this.projectService.addProject(newProject);
  }
}

Why this works: It centralizes API logic for reuse, while still adhering to NGXS’s unidirectional data flow (state updates happen only via actions). Just be careful not to put too much state-related logic in the service—keep state mutations strictly in your state class.

Which Approach Should You Choose? #

• Simple use cases: Go with the first option (direct action handler) for its simplicity.
• Complex side effects: Use NGXS Effects to keep your state class clean and focused on state mutations.
• Reusable API logic: Use a dedicated service, but always dispatch actions to update the state (never mutate state directly from the service).

内容的提问来源于stack exchange，提问作者Garth Mason