Filter Records
Filter Records: applies a visual filter/sort/limit to an already-fetched array of records, client-side.
Filter Records narrows and orders an items array of records without touching the server: the filter, sorting and limit are configured on the node exactly like Query Records' visual filter, but evaluated locally against the incoming array. The result comes out on items with count alongside; modified fires whenever the output recomputes, including the automatic re-runs an input or a record change starts. Use filter (signal) to re-evaluate on demand — that run also reports done/failure and then completed — and enabled to bypass.
When to use it
Deriving multiple views from one fetched result set — tabs, local search-as-you-type, secondary sorts — without re-querying. When the full data set should never reach the client, filter in the query itself (Query Records) instead.
At a glance
| Category | Data |
| Type name | FilterDBModels |
| Available in | browser, cloud |
| SSR compatibility | safe |
| Provided by | noodl-runtime |
Inputs
Values
| Name | Type | Default | Description |
|---|---|---|---|
enabled | Boolean | true | Passes every record through unchanged when off, rather than emptying the result |
items | Array | — | The records to filter, normally the Items output of a Query Records node |
runOnChange-enabled | Boolean | true | Whether a new value on Enabled re-runs this node. On by default; untick to make this input passive so only the control signal runs it |
runOnChange-filterSettings | Boolean | true | Whether a new value on Filter settings re-runs this node. On by default; untick to make this input passive so only the control signal runs it |
runOnChange-items | Boolean | true | Whether a new value on Items re-runs this node. On by default; untick to make this input passive so only the control signal runs it |
runOnChange-records | Boolean | true | Whether a new value on Record changes re-runs this node. On by default; untick to make this input passive so only the control signal runs it |
Signals
| Name | Type | Default | Description |
|---|---|---|---|
filter | Signal | — | Re-runs the filter now. This is additional to it re-running when Items, Enabled, the filter settings or the records themselves change; untick any of those under Run On Value Change to stop it |
Outputs
Values
| Name | Type | Default | Description |
|---|---|---|---|
count | Number | — | How many records are in the result after Skip and Limit, not how many matched the filter |
firstItemId | String | — | Id of the first record in the result, and nothing at all when the result is empty |
items | Array | — | The records that matched, after Sorting, Skip and Limit have been applied |
Signals
| Name | Type | Default | Description |
|---|---|---|---|
completed | Signal | — | Fires after every invocation, whatever the outcome — wire this to carry on regardless. Failure still fires and still carries its reason, so this cannot hide an error |
done | Signal | — | Fires once a Filter you triggered has run and Items is up to date |
modified | Signal | — | Fires each time the result has been rebuilt, including when the same records come back and including runs nobody triggered; wire Done for the outcome of a Filter you triggered |
Failure outputs
| Name | Type | Default | Description |
|---|---|---|---|
error | String | — | Why the most recent failed run failed, kept after a later run succeeds |
failure | Signal | — | Fires when the filter could not be applied, or when Filter was triggered with nothing on Items |
Dynamic ports
This node's port list changes at runtime (runtime-discovered, editor-adapter); the tables above may be incomplete for a given instance.
Filter input ports are generated by the editor from the visual filter definition (FilterRecordsAdapter) and the selected class schema.
Ports at runtime
Filter-value inputs are generated from the visual filter you build in the editor (each 'value' placeholder becomes an input port) — runtime-discovered + editor-adapter, same mechanism as Query Records.
Patterns
- One Query Records fanned into several Filter Records: one fetch, many live views.
Watch out for
- Client-filtering an unlimited query as a substitute for server-side where/limit — the full class still crosses the network.
Examples
One query, two tabs: client-side Filter Records views
One Query Records fetch fans out into two Filter Records nodes — 'open' and 'done' — each feeding its own Repeater. The filtering happens client-side against the already-fetched array, so switching tabs costs nothing and both views stay live as the underlying query updates. Filter in the query itself only when the excluded data shouldn't reach the client at all.
Related nodes
Query Records, Array Filter, Repeater
This page is generated from node-catalog-enriched.json. Do not edit it by hand — run npm run docs:nodes to regenerate, and fix the source enrichment instead.