# Add a filter to a list we already have

Add a filter to a list we already have: Name the list and what you want to narrow it by, and get a working filter control for it.

Source: https://codeherder.com/starter-briefs/add-a-filter-to-a-list/

Starter briefs

Name the list and what you want to narrow it by, and get a working filter control for it.

[Request access →](https://codeherder.com/get-started/#request-access) [Part of: Ship a small feature →](https://codeherder.com/use-cases/ship-a-small-feature/)

## The brief

Copy this text as it is, or change the specifics to match your own case, then file it as a task.

Copy this and file it as a task

Copy brief

```
We have a list view that already supports paging, but there is no way to narrow it down by one property we care about. Add a filter control for that property, wire it into the existing query so it actually narrows the results on the server rather than just hiding rows on screen, and keep it working together with paging and any sorting already there.
```

## Why this works

It names one list, one property to filter by, and one constraint that keeps the change checkable: the real query itself has to narrow, regardless of what's rendered. That makes a wrong implementation, hiding rows on the client instead, easy to spot in review.

How it runs

## Plan, code, review, merge, verify

1. plan Reads how the list's existing query is wired, along with its paging and any sorting. Decides where a new filter parameter fits without breaking them.
2. code Adds the filter control and threads the parameter through to the query; paging and sorting keep working alongside it.
3. review Checks the filter narrows the actual server-side result set, and that an empty filter still shows everything.
4. merge Opens a pull request that covers only the one filter.
5. verify Confirms filtering still works alongside paging and sorting after the change.

## What you need on hand

- The list and the property to filter by
- The query or endpoint that already backs the list
- A person to check the filter narrows the real result set, and not merely the screen

## Done when

- Setting the filter shows only matching rows
- Clearing the filter shows the full list again
- Paging and any existing sorting still work with the filter applied

## Proof, not a promise

No real task in examples.ts matches this brief's exact shape yet. What's real is the mechanism: an agent adds a filter through the same query the list already uses. Paging and sorting keep working, instead of drifting out of sync with a client-side hide.

Keep going

## Related briefs

[A label that is wrong in one place only Name the one screen where a label or copy string says the wrong thing, and get it corrected everywhere it needs to be.](https://codeherder.com/starter-briefs/label-wrong-in-one-place/) [Delete a dead flag and every reference to it Name the flag that always resolves one way now. Get it and its dead branch removed.](https://codeherder.com/starter-briefs/delete-a-dead-flag/) [Pull one duplicated block into one place Point at the same logic copied into more than one place, and get it merged into one shared version.](https://codeherder.com/starter-briefs/pull-duplicated-code-into-one-place/)

[← See every brief](https://codeherder.com/starter-briefs)