In an NgRx SignalStore, when a reusable paging feature needs the host store's loader, when do you declare a typed input and when use withFeature?

## The problem: a feature that needs its host A custom SignalStore feature built with `signalStoreFeature` is easiest to reuse when it owns everything it touches. Real features often need something from the store they are added to. Take a `withPageNavigation()` feature that adds `pageIndex` plus `nextPage()` and `previousPage()` methods for both a products store and a users store. Moving to the next page is shared logic, but **loading** that page is not: the products store calls a products API and the users store calls a users API. The feature needs the host's loader. NgRx 22 gives two ways to express that dependency: a **typed input** on the feature, and the `withFeature` utility. ## Option 1: typed input on signalStoreFeature `signalStoreFeature` accepts an optional first argument describing what the host must already contain. It is built with the `type` helper from `@ngrx/signals`: - `{ state: type<...>() }` — state slices the host must have; - `{ props: type<...>() }` — properties, such as signals or services exposed with `withProps`; - `{ methods: type<...>() }` — methods, such as `loadPage(pageIndex: number): void`. Inside the feature those members are available and fully typed. If a store adds the feature without them, the `signalStore(...)` call **fails to compile** — the error surfaces at the store, not at runtime. `SignalStoreFeatureType<typeof withX>` can extract one feature's shape to reuse as another feature's input. The cost is **coupling by name**: the feature dictates that the host's method is called `loadPage`. A users store whose loader is `fetchUsers` must rename it or add an adapter method. The docs recommend loosely coupled, independent features where possible. ## Option 2: withFeature `withFeature` (added in NgRx 19.1) takes a callback that receives the store built so far — its state signals, props and methods, plus the writable state source — and returns a feature. The feature itself declares no input; it takes plain function arguments instead: 1. Write `withPageNavigation(loadPage: (pageIndex: number) => void)` as an ordinary feature with no typed input. 2. In each store, add `withFeature((store) => withPageNavigation((i) => store.fetchUsers(i)))` after the features that define `fetchUsers`. 3. The feature calls whatever it was given, and never learns the host's member names. This keeps the feature **independent of the host's internal structure**, and it works for inputs that are not members at all: a computed value, a service call or a constant. ## Choosing between them | Concern | Typed input (`type<...>()`) | `withFeature` | |---|---|---| | Where the dependency is declared | In the feature's signature | At the store, in the callback | | Coupling to host names | High: host must use the exact names | None: host passes values explicitly | | Compile-time safety | Yes, the store fails to compile | Yes, the callback is typed | | Best for | Features that genuinely extend a known shape, e.g. `EntityState` | Features that need a callback or a value | | Readability at the store | Hidden: you must open the feature to see its needs | Visible in the store definition | A rule that works well: use a typed input when the feature is defined **in terms of** a well-known shape (a selection feature on top of `EntityState<Entity>`), and `withFeature` when the feature just needs a function or value from the host. ## Traps worth knowing - **Order still applies.** Both approaches only see members declared **before** them in the `signalStore(...)` argument list. - **A known TypeScript issue.** Combining several custom features that have static input but no generic parameter can produce unexpected compile errors. The docs' workaround is an unused generic: `function withZ<_>() { ... }`. - **Deep signals in generic features.** Since NgRx 22, a generic custom feature sees a state slice such as `Entity | null` as `DeepSignalOf<Entity | null>` rather than a plain `Signal`, because unions containing object literals now produce deep signals. - **Do not reach for inheritance.** Neither option needs a base class; if a feature needs half the host store, it is probably two features. - **Hide the feature's internals.** Members whose names start with `_` are private to the store, so a feature can keep helper state or methods out of the public API that components see. ## Testing each style A feature with a typed input is tested by building a tiny `signalStore(...)` that supplies the required members, often as stubs, then adds the feature. A feature used through `withFeature` is easier: its dependency is an ordinary function argument, so the test passes a spy such as a recorded list of requested page indexes and asserts on it, with no fake host members at all. That testability difference is a practical reason teams lean towards `withFeature` for features that call back into their host.