fix(perf): debounce search input to prevent excessive filter re-renders#1990
fix(perf): debounce search input to prevent excessive filter re-renders#1990anshul23102 wants to merge 1 commit into
Conversation
|
@anshul23102 is attempting to deploy a commit to the s3dfx-cyber's projects Team on Vercel. A member of the Team first needs to authorize it. |
👋 Thanks for opening a PR, @anshul23102!Your PR has entered the 🚦 PR Review Pipeline.
🔄 Review Flow
A pipeline status comment may appear automatically as your PR progresses. ✅ Contributor Checklist
|
|
Warning Review limit reached
Next review available in: 49 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ 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 |
💬 Faster Reviews & AssignmentsHi @anshul23102, for faster coordination and smoother communication, consider joining our Discord community: Useful Channels
|
|
✅ DCO Sign-off VerifiedHi @anshul23102 👋 All commits in this PR contain valid Thank you for following the DCO requirements 🚀 |
🚦 PR Review Pipeline
Last updated: Wed, 01 Jul 2026 21:38:07 GMT |
🤖 TENET Agent Review📋 SummaryThis pull request introduces a 🔐 Security FindingsNo security issues found. 🧹 Code Quality
✅ What's Done Well
📝 Overall Verdict[APPROVE] - The PR provides a correct and effective performance fix with no security concerns. |
The org search input and mentor search input triggered a full filter/render operation on every keystroke, causing 15+ synchronous filter operations when typing a typical query. This adds a debounce(fn, delay) utility and wraps both the org search and mentor search filter calls with a 300ms debounce, so filtering only runs once the user pauses typing. Fixes S3DFX-CYBER#1970 Signed-off-by: Anshul Jain <anshul23102@iiitd.ac.in>
4b03d8e to
a3f2894
Compare
🤖 TENET Agent Review📋 SummaryThis pull request introduces a 🔐 Security FindingsNo security issues found. 🧹 Code Quality
✅ What's Done Well
📝 Overall Verdict[APPROVE] - The PR provides a correct and effective solution to a performance issue with good code quality. |
|
There was a problem hiding this comment.
1 issue found and verified against the latest diff
Confidence score: 4/5
- In
src/js/app.js, the debounce flow is only partially applied, so controls that still callapplyFilters()/renderMentorFinderdirectly can race with a pending debounced call and trigger redundant or out-of-order renders, which can undermine the PR’s performance goal and occasionally show briefly inconsistent results — route all filter-entry paths through one debounced/cancel-aware handler (or cancel pending work before direct calls) before merging.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/js/app.js">
<violation number="1" location="src/js/app.js:2482">
P2: In a performance-focused PR aiming to prevent excessive re-renders, the debounce setup here leaves a gap: other filter controls call `applyFilters()` (or `renderMentorFinder`) directly without canceling a pending debounced search timer first. Because these functions read fresh DOM state on every call, the delayed invocation will re-process the same already-rendered state and trigger a redundant full filter/render cycle.
Consider making the debounce cancelable and clearing the pending timer before synchronous filter invocations, or having `applyFilters` short-circuit when no input state has actually changed.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
|
||
| // Wire up filter event listeners | ||
| document.getElementById('searchInput')?.addEventListener('input', applyFilters); | ||
| const debouncedApplyFilters = debounce(applyFilters, 300); |
There was a problem hiding this comment.
P2: In a performance-focused PR aiming to prevent excessive re-renders, the debounce setup here leaves a gap: other filter controls call applyFilters() (or renderMentorFinder) directly without canceling a pending debounced search timer first. Because these functions read fresh DOM state on every call, the delayed invocation will re-process the same already-rendered state and trigger a redundant full filter/render cycle.
Consider making the debounce cancelable and clearing the pending timer before synchronous filter invocations, or having applyFilters short-circuit when no input state has actually changed.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/js/app.js, line 2482:
<comment>In a performance-focused PR aiming to prevent excessive re-renders, the debounce setup here leaves a gap: other filter controls call `applyFilters()` (or `renderMentorFinder`) directly without canceling a pending debounced search timer first. Because these functions read fresh DOM state on every call, the delayed invocation will re-process the same already-rendered state and trigger a redundant full filter/render cycle.
Consider making the debounce cancelable and clearing the pending timer before synchronous filter invocations, or having `applyFilters` short-circuit when no input state has actually changed.</comment>
<file context>
@@ -2463,11 +2479,13 @@ document.addEventListener('DOMContentLoaded', () => {
// Wire up filter event listeners
- document.getElementById('searchInput')?.addEventListener('input', applyFilters);
+ const debouncedApplyFilters = debounce(applyFilters, 300);
+ document.getElementById('searchInput')?.addEventListener('input', debouncedApplyFilters);
document.getElementById('categoryFilter')?.addEventListener('change', applyFilters);
</file context>
|
Hi @S3DFX-CYBER, following up on this PR - it addresses the search debounce issue (#1970) and has been open for a while awaiting review. Could you please take a look when you get a chance, and apply the appropriate GSoC labels if it looks good? Thanks for your time. |



Description
The organization search input and mentor search input triggered a full filter/render operation on every single keystroke without debouncing, causing 15+ synchronous filter operations when typing a typical search query, resulting in UI sluggishness and unnecessary DOM thrashing.
Root Cause
The
inputevent listeners forsearchInputandmentorSearchInputcalledapplyFilters/renderMentorFinderdirectly with no debounce wrapper.Fix
debounce(fn, delay)utility function.searchInputlistener (and the syncedhero-searchinput) with a 300ms debounced call toapplyFilters.mentorSearchInputlistener with a 300ms debounced call torenderMentorFinder.Testing
node --checkthat the modified file has valid syntax.Fixes #1970