⚡ Bolt: Optimize Navbar scroll listener#83
Conversation
…ame and passive option Co-authored-by: Animesh-jsx <159705118+Animesh-jsx@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
💡 What: Wrapped the
handleScrollstate update inrequestAnimationFrameand added{ passive: true }to thewindow.addEventListener. Also added proper cleanup to cancel pending animation frames on unmount.🎯 Why: The scroll event in
src/components/layout/Navbar.tsxwas firing synchronously on the main thread, potentially causing layout thrashing and scroll jank, especially on mobile devices or lower-end hardware. State updates were happening faster than the browser could paint.📊 Impact: Reduces React state re-evaluations to exactly match the display refresh rate (e.g., 60fps), eliminating wasted computations. Unblocks the browser's compositor thread, ensuring smooth scrolling performance regardless of main thread activity.
🔬 Measurement: Profile the application in Chrome DevTools under the "Performance" tab. Observe the frequency of "Event: scroll" handlers and subsequent React "Commit" phases before and after the change; the handler execution time and main-thread blocking time should be visibly reduced.
PR created automatically by Jules for task 2296999881664803778 started by @Animesh-jsx