In Angular, how do you inject a service into a custom pipe, which injector resolves it, and how many pipe instances does a template create?

## Injecting into a pipe A pipe class takes part in dependency injection just like a directive. The current style is the **`inject()` function** in a field initializer: ```ts @Pipe({ name: 'statusLabel' }) export class StatusLabelPipe implements PipeTransform { private readonly labels = inject(StatusLabels); transform(code: string): string { return this.labels.lookup(code); } } ``` Constructor parameters work too, but `inject()` is the recommendation for new code. ## Which injector resolves it A pipe is resolved from the **element injector of the node where the pipe is used**, then up the element-injector tree, then the environment injectors, as if the pipe were a directive on that element. Two consequences: - providers declared by a component or directive on an **ancestor element** are visible to the pipe; - a component's **`viewProviders` are not** visible to pipes used on that component's host element; the framework explicitly disables that access when it creates the pipe. Pipes themselves cannot declare `providers`; `@Pipe` has no such option. ## How many instances exist Angular creates **one pipe instance per usage in a view**: - `{{ a | statusLabel }}` and `{{ b | statusLabel }}` in the same template are two instances; - a pipe inside an `@for` row gets a new instance for each row's view; - the instances are destroyed with their view, and a pipe that implements `ngOnDestroy` gets that hook called. So a pipe instance is not a singleton, and state stored on it is per usage. Anything that must be shared, such as a cache of translations, belongs in an injected service. | Question | Answer | |---|---| | Can a pipe call `inject()`? | Yes, in a field initializer or the constructor | | Starting point for resolution | The element where the pipe is used | | Sees the host component's `viewProviders`? | No | | Instances per template | One per usage, per view | | Lifecycle hook available | `ngOnDestroy` | ## What to inject, and what not to - **Good fits**: stateless lookups, formatting configuration such as `LOCALE_ID`, a shared cache. - **Careful**: a service whose data changes over time. A pure pipe will not re-run just because the service's data changed; pass the changing value as an argument, or read it from a signal passed in, so Angular can see the dependency. - **Avoid**: services that perform HTTP calls from `transform`. The pipe is invoked during change detection; a request per evaluation is easy to trigger by accident, and the result arrives asynchronously anyway, which is the async pipe's job. ## The reverse direction: pipes in services The Angular guide advises **against injecting a pipe class into a service or component** to reuse its logic. Pipes are template operators, not injectable services. Extract the transformation into a plain exported function, have the pipe's `transform` delegate to it, and import the function wherever else it is needed. For built-in pipes, the equivalent functions are exported from `@angular/common`: `formatDate`, `formatCurrency`, `formatNumber` and `formatPercent`. ## A worked diagnosis A team reports that a `currencyLabel` pipe keeps returning a stale label after the user switches the display currency in settings. The pipe injects a `Settings` service and reads `settings.currency` inside `transform`. The pipe is pure, and its only input, the amount, did not change, so Angular never called `transform` again. The fix is not `pure: false`; it is to make the dependency visible: `{{ amount | currencyLabel: settings.currency() }}` with the setting held in a signal, so both the view refresh and the pipe re-run happen when it changes. ## Testing a pipe with dependencies 1. For a pipe without dependencies, instantiate it directly and call `transform`. 2. For a pipe that calls `inject()`, create it inside an injection context, for example with `TestBed.runInInjectionContext(() => new StatusLabelPipe())`, after providing test doubles through `TestBed.configureTestingModule`. 3. Test the extracted plain function separately; most of the logic lives there.