feat: add favorites tab to knowledge center per id 694#1179
Conversation
📝 WalkthroughSummary by CodeRabbitRelease Notes
WalkthroughThe PR adds a Favorites tab to the Knowledge Center page backed by a new SWR fetch, maps server favorites into the page's unified content shape, and routes filtered content through that list when the tab is active. Separately, the Resident Home sidebar favorites list is replaced with a grouped accordion component that organizes items by content type. ChangesFavorites UI Enhancements
🚥 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 docstrings
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: 2
🤖 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/pages/knowledge-center/ResidentKnowledgeCenter.tsx`:
- Around line 111-117: The useSWR hook fetching `/api/open-content/favorites`
uses a hard-coded per_page=500 limit, which causes the favorites count to be
incorrect for users with more than 500 favorites since the count is derived from
the returned data.length. Modify the implementation to use the total count
metadata from the ServerResponseMany response object instead of relying on the
length of the returned items array, ensuring the favorites tab displays the
accurate total count regardless of the pagination limit. Additionally, ensure
that any client-side rendering or count calculations throughout the component
use this metadata-based total rather than the truncated data length.
In `@frontend/src/pages/student/ResidentHome.tsx`:
- Line 173: The accordion container has overflow-hidden applied which clips
items when the content exceeds the max-h-[800px] height constraint, making
excess favorites unreachable. Remove the overflow-hidden class from the
className attribute on the container element (around line 173) and replace it
with overflow-y-auto to allow scrolling within the constrained height, making
all items accessible. Apply the same fix to the other similar accordion
container around lines 195-199.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: d832655b-5b06-4cf7-afd7-0cdd6708f7d4
📒 Files selected for processing (2)
frontend/src/pages/knowledge-center/ResidentKnowledgeCenter.tsxfrontend/src/pages/student/ResidentHome.tsx
| const { data: favData, mutate: mutateFavorites } = useSWR< | ||
| ServerResponseMany<OpenContentItem> | ||
| >( | ||
| // Always fetched (like the other tabs) so the Favorites count shows | ||
| // even when the tab isn't active. | ||
| `/api/open-content/favorites?page=1&per_page=500&search=${searchQuery}` | ||
| ); |
There was a problem hiding this comment.
Favorites count/list can silently truncate due fixed per_page=500 + data.length counting.
The endpoint is paginated, but this request hard-limits to 500 items and the tab count is derived from only the returned page size. Users with more than 500 favorites will see an incorrect count and won’t be able to access the remainder.
Suggested direction
-const { data: favData, mutate: mutateFavorites } = useSWR<ServerResponseMany<OpenContentItem>>(
- `/api/open-content/favorites?page=1&per_page=500&search=${searchQuery}`
-);
+const { data: favData, mutate: mutateFavorites } = useSWR<ServerResponseMany<OpenContentItem>>(
+ `/api/open-content/favorites?page=${currentPage}&per_page=${itemsPerPage}&search=${searchQuery}`
+);
- Favorites ({favData?.data.length ?? 0})
+ Favorites ({favData?.meta?.total ?? 0})If you paginate server-side for favorites, also avoid client-side re-slicing that same list.
Also applies to: 579-579
🤖 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/pages/knowledge-center/ResidentKnowledgeCenter.tsx` around lines
111 - 117, The useSWR hook fetching `/api/open-content/favorites` uses a
hard-coded per_page=500 limit, which causes the favorites count to be incorrect
for users with more than 500 favorites since the count is derived from the
returned data.length. Modify the implementation to use the total count metadata
from the ServerResponseMany response object instead of relying on the length of
the returned items array, ensuring the favorites tab displays the accurate total
count regardless of the pagination limit. Additionally, ensure that any
client-side rendering or count calculations throughout the component use this
metadata-based total rather than the truncated data length.
There was a problem hiding this comment.
Correct but definitely not as severe as stated, Id argue against fixing in this PR.
| return ( | ||
| <div | ||
| key={title} | ||
| className="rounded-lg border border-border overflow-hidden" |
There was a problem hiding this comment.
Accordion can cut off favorites when a group grows beyond 800px.
With overflow-hidden on the container and max-h-[800px] when open, excess items are clipped and cannot be reached.
Suggested fix
-<div
- className={`transition-[max-height] duration-300 ${
- open
- ? 'max-h-[800px]'
- : 'max-h-0 overflow-hidden'
- }`}
->
+<div
+ className={`transition-[max-height] duration-300 ${
+ open
+ ? 'max-h-[70vh] overflow-y-auto'
+ : 'max-h-0 overflow-hidden'
+ }`}
+>Also applies to: 195-199
🤖 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/pages/student/ResidentHome.tsx` at line 173, The accordion
container has overflow-hidden applied which clips items when the content exceeds
the max-h-[800px] height constraint, making excess favorites unreachable. Remove
the overflow-hidden class from the className attribute on the container element
(around line 173) and replace it with overflow-y-auto to allow scrolling within
the constrained height, making all items accessible. Apply the same fix to the
other similar accordion container around lines 195-199.
CK-7vn
left a comment
CK-7vn
left a comment
There was a problem hiding this comment.
Approving, just gotta fix that null check, after I fixed it, everything worked great.
| const { data: favData, mutate: mutateFavorites } = useSWR< | ||
| ServerResponseMany<OpenContentItem> | ||
| >( | ||
| // Always fetched (like the other tabs) so the Favorites count shows | ||
| // even when the tab isn't active. | ||
| `/api/open-content/favorites?page=1&per_page=500&search=${searchQuery}` | ||
| ); |
There was a problem hiding this comment.
Correct but definitely not as severe as stated, Id argue against fixing in this PR.
| : 'fill-brand-gold text-brand-gold' | ||
| }`} | ||
| /> | ||
| Favorites ({favData?.data.length ?? 0}) |
There was a problem hiding this comment.
This caused an error for me when I didn't have any favorites. Should be able to replace it with the memoized value above. so favData?.data.length ?? 0 goes to favoritesContent.length
2 participants
Pre-Submission PR Checklist
Description of the change
Added the favorites tab to the knowledge center in resident facing side of app along with the favorites accordion on the dashboard.
NOTE: We should add the favorting of the specific section of a library. Create a new ticket for this.
REVIEWERS NOTE: Should we remove the icon from the tab for favorites?
Screenshot(s)