fix: filter release targets by search query client-side#955
fix: filter release targets by search query client-side#955adityachoudhari26 merged 1 commit intomainfrom
Conversation
The search bar was accepting input but never applying it as a filter. The query value is passed to the API which doesn't support text filtering, so add client-side filtering by resource name and identifier instead. Co-authored-by: Aditya Choudhari <adityachoudhari26@users.noreply.github.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 9 minutes and 25 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
There was a problem hiding this comment.
Pull request overview
Adds client-side filtering on the deployment release targets page so the search input actually filters the displayed targets (since the underlying endpoint doesn’t support text search).
Changes:
- Apply a client-side filter by resource
nameandidentifierusing the debounced search text. - Combine the new search filter with existing job status + version filters.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const q = searchDebounced.toLowerCase(); | ||
| const isMatchingSearch = | ||
| q === "" || | ||
| rt.resource.name.toLowerCase().includes(q) || | ||
| rt.resource.identifier.toLowerCase().includes(q); | ||
| return isMatchingJobStatus && isMatchingVersion && isMatchingSearch; |
There was a problem hiding this comment.
q is derived from searchDebounced, but useResource() initializes its state from searchParams.get("resource") while updating the URL param named query. This means a shared/refreshed URL like ?query=foo will not restore the filter, and the UI can get out of sync with the URL. Consider using a single consistent search param key (read + write the same key).
| const q = searchDebounced.toLowerCase(); | ||
| const isMatchingSearch = |
There was a problem hiding this comment.
searchDebounced.toLowerCase() is computed inside the .filter() callback, so it gets recomputed once per release target. Since q is constant for the whole filter operation, compute/normalize it once outside the callback (and optionally trim() it) to avoid unnecessary work and make the filtering logic clearer.
The search bar on the release targets page was accepting input but never applying it as a filter. The API endpoint doesn't support text filtering, so client-side filtering by resource name and identifier is added instead.
Fixes #954
Generated with Claude Code