feat: add label filtering and sorting to IssueBacklog (#461)#487
Conversation
|
@MAN7A-afk is attempting to deploy a commit to the ritik4ever's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@MAN7A-afk Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
Warning Review limit reached
More reviews will be available in 50 minutes and 59 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, 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 include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughIssueBacklog now derives unique labels from the issues array, maintains activeLabels and sortKey state, and computes visibleIssues via useMemo by filtering on active labels and applying sort logic. The UI adds interactive label filter chips, a sort dropdown (default/complexity/points asc-desc), a conditional clear button, and renders per-issue label chips that reflect selection state. A comprehensive test suite validates filtering (single/multiple labels), sorting (complexity and points), state resets, empty states, and loading behavior. ChangesIssueBacklog Filtering and Sorting
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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.
Actionable comments posted: 1
🧹 Nitpick comments (1)
frontend/src/components/IssueBacklog.test.tsx (1)
86-103: ⚡ Quick winSimplify the empty-state test to match its stated purpose.
The test name says "shows empty state message when no issues match the filter," but the implementation is convoluted with multiple
cleanup()andrender()calls. It ultimately just verifies that the message appears whenissues={[]}, not when active filters produce zero results.Since OR-logic filtering guarantees at least one match per active label (labels are derived from existing issues), the "no matches" case only occurs when the issues array is empty or changes externally. The current test is correct but confusing.
♻️ Proposed refactor to clarify intent
- it("shows empty state message when no issues match the filter", () => { + it("shows empty state message when no issues are available", () => { - render(<IssueBacklog issues={MOCK_ISSUES} />); - - // "docs" label only on issue 4; then also filter "backend" — but let's - // use a label that exists on no issue by passing a custom set - const noMatchIssues: OpenIssue[] = [ - { id: "x", title: "X", summary: "s", complexity: "Trivial", points: 100, labels: ["alpha"] }, - ]; - cleanup(); - render(<IssueBacklog issues={noMatchIssues} />); - - fireEvent.click(screen.getByRole("button", { name: "alpha" })); - // deactivate to get 0 results — use an issue list where filter yields nothing - // Easier: render with empty issues and no labels - cleanup(); render(<IssueBacklog issues={[]} />); expect(screen.getByText(/No issues match/i)).toBeInTheDocument(); });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@frontend/src/components/IssueBacklog.test.tsx` around lines 86 - 103, The test for IssueBacklog is overly complex; simplify it to directly exercise the empty-state scenario by rendering <IssueBacklog issues={[]} /> once and asserting the "No issues match" message. Remove the intermediate renders, cleanup() calls, and the label click (references: IssueBacklog, MOCK_ISSUES, the test block named "shows empty state message when no issues match the filter"); optionally rename the test to "shows empty state message when issues array is empty" to match intent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/src/components/IssueBacklog.tsx`:
- Around line 161-163: The empty-state message in IssueBacklog always says "No
issues match the selected filters." even when there are simply no issues and no
filters applied; update the render logic in IssueBacklog to check both
visibleIssues.length === 0 and whether any filters are active (e.g., the
component's filters state or props like
selectedFilters/activeFilters/assigneeFilter); if no issues and no active
filters show a neutral message like "No issues yet" or "There are no issues.",
otherwise keep "No issues match the selected filters." so the message reflects
whether filters are the cause.
---
Nitpick comments:
In `@frontend/src/components/IssueBacklog.test.tsx`:
- Around line 86-103: The test for IssueBacklog is overly complex; simplify it
to directly exercise the empty-state scenario by rendering <IssueBacklog
issues={[]} /> once and asserting the "No issues match" message. Remove the
intermediate renders, cleanup() calls, and the label click (references:
IssueBacklog, MOCK_ISSUES, the test block named "shows empty state message when
no issues match the filter"); optionally rename the test to "shows empty state
message when issues array is empty" to match intent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d303b25c-2456-47cd-95b8-22db3394e61c
📒 Files selected for processing (2)
frontend/src/components/IssueBacklog.test.tsxfrontend/src/components/IssueBacklog.tsx
| {visibleIssues.length === 0 ? ( | ||
| <p className="muted">No issues match the selected filters.</p> | ||
| ) : ( |
There was a problem hiding this comment.
Conditionally adjust the empty-state message based on whether filters are active.
The message "No issues match the selected filters." is shown whenever visibleIssues.length === 0, including when issues={[]} and no filters are active. In that case, the message is misleading because there are no selected filters.
💬 Proposed fix to show context-appropriate empty-state message
- {visibleIssues.length === 0 ? (
- <p className="muted">No issues match the selected filters.</p>
- ) : (
+ {visibleIssues.length === 0 ? (
+ <p className="muted">
+ {hasActiveFilters
+ ? "No issues match the selected filters."
+ : "No issues available."}
+ </p>
+ ) : (🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@frontend/src/components/IssueBacklog.tsx` around lines 161 - 163, The
empty-state message in IssueBacklog always says "No issues match the selected
filters." even when there are simply no issues and no filters applied; update
the render logic in IssueBacklog to check both visibleIssues.length === 0 and
whether any filters are active (e.g., the component's filters state or props
like selectedFilters/activeFilters/assigneeFilter); if no issues and no active
filters show a neutral message like "No issues yet" or "There are no issues.",
otherwise keep "No issues match the selected filters." so the message reflects
whether filters are the cause.
2 participants
What changed
Added label filter chips generated dynamically from unique issue labels
Implemented multi-select label filtering using OR logic
Added sorting options for:
Added a "Clear filters" button to reset active filters and sorting
Updated
IssueBacklog.tsxto handle filtering and sorting state cleanlyAdded Vitest coverage to verify filtering by label reduces visible issues correctly
Testing done
Related issues
Closes #461
Checklist
Summary by CodeRabbit
New Features
Tests