feat(filter): add category filter in search panel#50
Conversation
📝 WalkthroughWalkthroughAdds category-based filtering: extends SearchFilters with Changes
Sequence Diagram(s)sequenceDiagram
participant User as User
participant UI as SearchBar (UI)
participant Store as AppStore
participant List as RepoList
User->>UI: Toggle category button
UI->>Store: update local searchFilters.categories
Store-->>UI: updated customCategories / categories (derived)
UI->>List: applyFilters(filters including categories)
List-->>UI: filtered repo list returned
UI->>User: render filtered results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/components/SearchBar.tsx (1)
224-232: Consider the UX impact of excluding uncategorized repositories.When a category filter is active, repositories without a
custom_categoryare excluded from results. This is consistent with filtering by manually-assigned categories, but users may expect repositories to also match based on their auto-detected or default category.If this is the intended behavior (filtering only manually-categorized repos), the current implementation is correct. However, you might want to:
- Add a UI hint indicating the filter applies to manually-assigned categories only, or
- Consider a fallback to match against default category keywords if
custom_categoryis not set🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/SearchBar.tsx` around lines 224 - 232, The current filter using searchFilters.categories only checks repo.custom_category and thus excludes uncategorized repos; update the filtering in the block that references searchFilters.categories and filtered so that when repo.custom_category is falsy you fallback to matching against an automatic/default category or keyword set (e.g., call a helper like matchDefaultCategory(repo, searchFilters.categories) or check repo.auto_category/default_category) so repos without custom_category can still match, and/or add a clear UI hint near the category filter indicating it currently applies to manually-assigned categories only (adjust the label/tooltip for the category UI control).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/components/SearchBar.tsx`:
- Around line 224-232: The current filter using searchFilters.categories only
checks repo.custom_category and thus excludes uncategorized repos; update the
filtering in the block that references searchFilters.categories and filtered so
that when repo.custom_category is falsy you fallback to matching against an
automatic/default category or keyword set (e.g., call a helper like
matchDefaultCategory(repo, searchFilters.categories) or check
repo.auto_category/default_category) so repos without custom_category can still
match, and/or add a clear UI hint near the category filter indicating it
currently applies to manually-assigned categories only (adjust the label/tooltip
for the category UI control).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1e616864-fcab-4fb3-bd3c-48d83bc73e5c
📒 Files selected for processing (3)
src/components/SearchBar.tsxsrc/store/useAppStore.tssrc/types/index.ts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/components/SearchBar.tsx (1)
72-83:⚠️ Potential issue | 🟠 MajorRe-run filtering when category metadata changes.
Line 82 reruns
performSearch()for filter value changes, butapplyFilters()now also depends oncustomCategoriesandlanguage. Renaming categories, editing keywords, or switching locale leaves the current result set stale until some unrelated filter changes. Add those dependencies here, or memoizeapplyFiltersand depend on that.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/SearchBar.tsx` around lines 72 - 83, The effect that calls performSearch (defined inside useEffect) is missing dependencies for customCategories and language which applyFilters now relies on; update the dependency array of the useEffect that references performSearch to include customCategories and language (or alternatively memoize applyFilters with useCallback/useMemo and depend on the memoized function in the useEffect). Ensure references to performSearch/useEffect/searchFilters/applyFilters/customCategories/language are updated so renaming categories, editing keywords, or changing locale triggers performSearch().
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/components/SearchBar.tsx`:
- Around line 47-50: The code currently stores translated category names in
available/selected filters which breaks when language changes; change
persistence to use stable IDs: keep setAvailableCategories populated with
category ids (from getAllCategories(customCategories, language).filter(cat =>
cat.id !== 'all').map(cat => cat.id)) and ensure searchFilters.categories stores
cat.id values instead of names; update applyFilters and any
selection/serialization logic to resolve Category.name only at render time by
looking up the label from getAllCategories(...) or a categoriesById map. Apply
the same change to the other occurrences noted (lines referencing
available/selected category names and applyFilters).
---
Outside diff comments:
In `@src/components/SearchBar.tsx`:
- Around line 72-83: The effect that calls performSearch (defined inside
useEffect) is missing dependencies for customCategories and language which
applyFilters now relies on; update the dependency array of the useEffect that
references performSearch to include customCategories and language (or
alternatively memoize applyFilters with useCallback/useMemo and depend on the
memoized function in the useEffect). Ensure references to
performSearch/useEffect/searchFilters/applyFilters/customCategories/language are
updated so renaming categories, editing keywords, or changing locale triggers
performSearch().
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 84dd2675-98b2-4831-8ab0-bbfed4870bd0
📒 Files selected for processing (1)
src/components/SearchBar.tsx
| const allCategories = getAllCategories(customCategories, language) | ||
| .filter(cat => cat.id !== 'all') | ||
| .map(cat => cat.name); | ||
| setAvailableCategories(allCategories); |
There was a problem hiding this comment.
Use stable category IDs instead of translated names.
These paths treat the display label as the persisted filter value. Once language changes, default category names change too, so the selected chips lose their active state and applyFilters() can no longer resolve the inferred category objects for the existing selection. Store cat.id in searchFilters.categories and derive the current label from Category.name only at render time.
Also applies to: 491-495, 864-882
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/components/SearchBar.tsx` around lines 47 - 50, The code currently stores
translated category names in available/selected filters which breaks when
language changes; change persistence to use stable IDs: keep
setAvailableCategories populated with category ids (from
getAllCategories(customCategories, language).filter(cat => cat.id !==
'all').map(cat => cat.id)) and ensure searchFilters.categories stores cat.id
values instead of names; update applyFilters and any selection/serialization
logic to resolve Category.name only at render time by looking up the label from
getAllCategories(...) or a categoriesById map. Apply the same change to the
other occurrences noted (lines referencing available/selected category names and
applyFilters).
|
Closing this PR per maintainer decision: category filtering will remain in the left sidebar only to avoid duplicated/conflicting controls. |
1 participant
Summary
Resolve #28 by adding category filter support in the filter panel.
Changes
categoriestoSearchFilterscustom_categorymatching)Notes
This keeps behavior intuitive for users who manually manage categories and want category-level filtering from the filter panel.
Fixes #28
Summary by CodeRabbit