Bolt prompt to add a search feature
Use this to add search to an app already open in Bolt: debounced input, multi-word matching, highlighted results, keyboard navigation, and a query string synced to the URL. The matching logic lands in one pure, testable module, and the agent must demonstrate hit, miss, and special-character queries in the preview before stopping.
Last updated
Add a search feature to this app so users can find {{resource}} records by name and description.
Behavior:
- A search input in the header, focusable with the / key, with a clear button
- Debounce input by roughly 250ms so matching does not run on every keystroke
- Case-insensitive matching on name and description; treat multiple words as AND terms
- Highlight the matched substring in each result using a mark element, not custom spans with inline styles
- Show a result count, and when nothing matches, an empty state suggesting a spelling check or clearing filters
- Sync the query to the URL as ?q= so results survive a reload and can be shared; restore the input from the URL on load
- Keyboard support: arrow keys move through results, Enter opens the selected record, Escape clears and closes
Implementation:
- If the data is already client-side, filter in a memoized selector and do not mutate the underlying list
- If records come from an API, add a q parameter to the list endpoint and match server-side, keeping only the debounce in the browser
- Keep the logic in one module (src/lib/search.ts or equivalent) as a pure function I can unit test: given records and a query, return matches with their positions
Edge cases: an empty query shows the normal list, whitespace-only queries count as empty, queries containing regex characters like ( or * must not crash the matcher, and clearing the search restores the prior scroll position.
Finish by demonstrating three searches in the preview: a term with hits, a term with none, and a term containing a special character. Then list the files you changed.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Add a search feature to this app so users can find users records by name and description. Behavior: - A search input in the header, focusable with the / key, with a clear button - Debounce input by roughly 250ms so matching does not run on every keystroke - Case-insensitive matching on name and description; treat multiple words as AND terms - Highlight the matched substring in each result using a mark element, not custom spans with inline styles - Show a result count, and when nothing matches, an empty state suggesting a spelling check or clearing filters - Sync the query to the URL as ?q= so results survive a reload and can be shared; restore the input from the URL on load - Keyboard support: arrow keys move through results, Enter opens the selected record, Escape clears and closes Implementation: - If the data is already client-side, filter in a memoized selector and do not mutate the underlying list - If records come from an API, add a q parameter to the list endpoint and match server-side, keeping only the debounce in the browser - Keep the logic in one module (src/lib/search.ts or equivalent) as a pure function I can unit test: given records and a query, return matches with their positions Edge cases: an empty query shows the normal list, whitespace-only queries count as empty, queries containing regex characters like ( or * must not crash the matcher, and clearing the search restores the prior scroll position. Finish by demonstrating three searches in the preview: a term with hits, a term with none, and a term containing a special character. Then list the files you changed.
Same task in other tools
Questions about this prompt
Should filtering happen client-side or on the server?
It depends where the list already lives, which is why the prompt covers both branches. A few hundred client-side records filter fine in a memoized selector; once the list arrives paginated from an API, move matching server-side and keep only the debounce in the browser.
Search crashes when someone types ( or *. Why?
The generated matcher probably feeds raw input into new RegExp, which is exactly what the special-character edge case exists to catch. Ask for the query to be escaped before the pattern is built, or for plain substring matching, then retest with the same input.
How do I upgrade this to fuzzy matching later?
Ask for Fuse.js by name, or extend the pure function in the search module with a scoring pass. Keep its signature stable, records and query in, matches with positions out, so no component code has to change.