@loopback/docs

Version:

Documentation files rendered at [https://loopback.io](https://loopback.io)

github.com/loopbackio/loopback-next/tree/master/docs

44 lines (28 loc) • 1.96 kB

Markdown

--- lang: en title: 'API docs: context.bindingfilter' keywords: LoopBack 4.0, LoopBack 4, Node.js, TypeScript, OpenAPI sidebar: lb4_sidebar editurl: https://github.com/loopbackio/loopback-next/tree/master/packages/context permalink: /doc/en/lb4/apidocs.context.bindingfilter.html ---  [Home](./index.md) > [@loopback/context](./context.md) > [BindingFilter](./context.bindingfilter.md) ## BindingFilter interface A function that filters bindings. It returns `true` to select a given binding. <b>Signature:</b> ```typescript export interface BindingFilter ``` ## Remarks Originally, we allowed filters to be tied with a single value type. This actually does not make much sense - the filter function is typically invoked on all bindings to find those ones matching the given criteria. Filters must be prepared to handle bindings of any value type. We learned about this problem after enabling TypeScript's `strictFunctionTypes` check. This aspect is resolved by typing the input argument as `Binding<unknown>`. Ideally, `BindingFilter` should be declared as a type guard as follows: ```ts export type BindingFilterGuard<ValueType = unknown> = ( binding: Readonly<Binding<unknown>>, ) => binding is Readonly<Binding<ValueType>>; ``` But TypeScript treats the following types as incompatible and does not accept type 1 for type 2. 1. `(binding: Readonly<Binding<unknown>>) => boolean` 2. `(binding: Readonly<Binding<unknown>>) => binding is Readonly<Binding<ValueType>>` If we described BindingFilter as a type-guard, then all filter implementations would have to be explicitly typed as type-guards too, which would make it tedious to write quick filter functions like `b => b.key.startsWith('services')`. To keep things simple and easy to use, we use `boolean` as the return type of a binding filter function.