Paginate and memoize the list-heavy admin, social, and dashboard surfaces

[RUKAYAT-CODER]

Background
Several high-traffic surfaces render an entire collection at once and rebuild child action handlers on every render, so they become slow and janky as data grows. src/components/ui/Table.tsx renders every row with no windowing and rebuilds per-row handlers; src/components/notificationcenter.tsx maps the full notification list; src/components/admin/ApprovalQueue.tsx maps all submissions and recreates its approve/reject handlers each render; src/components/BulkActions.tsx rebuilds operation callbacks; src/components/social/FollowingSystem.tsx and src/components/social/SocialProfile.tsx render full follower/activity lists; src/components/dashboard/AdvancedDashboard.tsx re-derives its panel grid each render; and src/components/cms/MediaManager.tsx maps the whole upload queue. Row/item components are not memoized and the callbacks passed to them are new references every render.

Implementation Plan

• Add client-side pagination (or windowing, reusing the existing src/components/InfiniteList.tsx / react-window setup) to Table.tsx, notificationcenter.tsx, ApprovalQueue.tsx, MediaManager.tsx, FollowingSystem.tsx, and SocialProfile.tsx.
• Extract row/item components and wrap them in React.memo, and stabilize the action callbacks (approve/reject, dismiss, select, remove, bulk ops) with useCallback in ApprovalQueue.tsx, notificationcenter.tsx, BulkActions.tsx, and Table.tsx.
• Memoize derived/grouped data with useMemo in AdvancedDashboard.tsx and the feeds.
• Add benchmarks/metrics capturing before/after render counts and timings.
• Add regression tests where applicable.
• Document the change.

Files in Scope (8)
src/components/ui/Table.tsx, src/components/notificationcenter.tsx, src/components/admin/ApprovalQueue.tsx, src/components/BulkActions.tsx, src/components/social/FollowingSystem.tsx, src/components/social/SocialProfile.tsx, src/components/dashboard/AdvancedDashboard.tsx, src/components/cms/MediaManager.tsx

Acceptance Criteria

• Measurable performance/efficiency improvement demonstrated with before/after numbers
• No regression in existing functionality
• Tests pass and code follows project standards
• Change is documented

Difficulty
Hard (Large)

[TheWeirdDee]

Hi Maintainer, I’d like to take on this issue.

I’ve reviewed the implementation plan and understand that this is a larger frontend performance refactor focused on reducing unnecessary renders, stabilizing callbacks, and avoiding rendering entire high-traffic collections at once.

I have experience with React/Next.js, TypeScript, component architecture, and frontend performance optimization. I’d approach this incrementally by first profiling the affected components to establish a baseline, then introducing pagination/windowing where appropriate, extracting and memoizing row/item components, stabilizing callbacks with useCallback, and memoizing expensive derived data with useMemo.

I’ll be careful to preserve existing behavior, especially around interactive operations such as approvals, notifications, bulk actions, social lists, and media management. I’ll also use the project’s existing InfiniteList/react-window setup where it makes sense rather than introducing another virtualization dependency.

For validation, I’ll capture before/after render counts and timing measurements, add regression tests for the affected interactions, run the existing test and project checks, and document the performance improvements and architectural changes.

No blockers on my end. I’m ready to take this on and work through the full scope.

[eulami]

Hi. I can create a good PR for this within 24 hours. Kindly assign it to me.

[grantfox-oss]

🦊 GrantFox — @TheWeirdDee has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #1136)
2. Your PR will be reviewed by the rinafcode maintainers

Good luck! Track your progress on GrantFox.