{"id":23543,"date":"2023-11-27T00:08:37","date_gmt":"2023-11-26T23:08:37","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/ngrx-signal-store-deep-dive-flexible-and-type-safe-custom-extensions\/"},"modified":"2023-12-11T18:01:26","modified_gmt":"2023-12-11T17:01:26","slug":"ngrx-signal-store-deep-dive-flexible-and-type-safe-custom-extensions","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/ngrx-signal-store-deep-dive-flexible-and-type-safe-custom-extensions\/","title":{"rendered":"NGRX Signal Store Deep Dive: Flexible and Type-Safe Custom Extensions"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 3 of 7 in the series “NGRX Signal Store”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. The new NGRX Signal Store for Angular: 3+n Flavors<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Smarter, Not Harder: Simplifying your Application With NGRX Signal Store and Custom Features<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. NGRX Signal Store Deep Dive: Flexible and Type-Safe Custom Extensions<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  4. The NGRX Signal Store and Your Architecture<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Using Angular’s Resource API with the NGRX Signal Store<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. The new Event API for the NgRx Signal Store: A Quantum of Redux<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Full-Cycle Reactivity in Angular: Signal Forms, Signal Store, Resources, & Mutation API<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    The NGRX Signal Store, released shortly after Angular 17, offers a very lightweight solution for state management. With no direct dependencies on RxJS, it relies entirely on Signals. However, its greatest strength is undoubtedly its high degree of expandability. With so-called custom features, recurring tasks can be implemented very easily in a central way.<\/p>\n

    The first example of custom features presented here is very straightforward. After that, things get a little more challenging: The consumer of a feature must be able to determine the names of the signals and methods set up by the feature. Otherwise, naming conflicts will arise quickly. As the following examples show, this does not contradict strict typing in TypeScript.<\/p>\n

    The examples shown here are inspired by an example from Marko Stanimirovi\u0107<\/a>, the NGRX core team member behind the Signal Store, and the Entity management solution @ngrx\/signals\/entity<\/code> shipped with the Signal Store.<\/p>\n

    \ud83d\udcc2 Source Code<\/a> (Branch: arc-signal-store-custom-typed)<\/p>\n

    Signal Store 101<\/h2>\n

    Before we start, I would like to quickly get everyone on board and summarize the most important aspects of the NGRX Signal Store. A detailed overview<\/a> can be found in my article here<\/a>.<\/p>\n

    The signal store comes with NGRX since version 17 and is located in the npm package @ngrx\/signals<\/code>. At the center is the signalStore<\/code> function, which creates a new Signal Store. Technically, this is an Angular service that receives signals, derived (calculated) signals, and methods for state management:<\/p>\n

    import {\n  patchState,\n  signalStore,\n  withHooks,\n  withMethods,\n  withComputed,\n  withState,\n} from '@ngrx\/signals';\n\n[\u2026]\n\nexport const FlightBookingStore = signalStore(\n\n  { providedIn: 'root' },\n\n  \/\/ State Properties\n  withState({\n    from: 'Paris',\n    to: 'London',\n    initialized: false,\n    flights: [] as Flight[],\n    basket: {} as Record<number, boolean>,\n  }),\n\n  \/\/ Calculated State\n  withComputed(({ flights, basket, from, to }) => ({\n    selected: computed(() => flights().filter((f) => basket()[f.id])),\n    criteria: computed(() => ({ from: from(), to: to() })),\n  })),\n\n  \/\/ Extension\n  withCallState(),\n\n  \/\/ Methods\n  withMethods((state) => {\n    const { basket, flights, from, to, initialized } = state;\n    const flightService = inject(FlightService);\n\n    return {\n      load: async () => {\n        if (!from() || !to()) return;\n\n        \/\/ Updating the extension\u2019s state (callState)\n        patchState(state, setLoading());\n\n        const flights = await flightService.findPromise(from(), to());\n        patchState(state, { flights });\n\n        \/\/ Updating the extension\u2019s state (callState)\n        patchState(state, setLoaded());\n\n      },\n    };\n\n  })\n);<\/code><\/pre>\n
    Interestingly, the Signal Store is already based entirely on so-called features in this first expansion stage: withState<\/code> , withComputed<\/code> or withMethods<\/code> are three features that enrich the store with properties (signals and calculated signals) and methods.<\/p>\n
    The function withCallState<\/code> is a first simple custom feature that introduces a callState<\/code> Signal. This signal informs, among other things, whether data is currently being loaded or whether the loading process has already been completed. It introduces the following signals:<\/p>\n