New navigation scroll into view secondary item

[paulinashakirova]

Summary

This PR resolves [SideNav] Smooth scroll to active element in side panel issue.

Screen.Recording.2025-09-10.at.11.05.17.mov

[weronikaolejniczak]

non-blocking suggestion:

The current implementation is absolutely fine. What we can do to make it better is encapsulate it in a reusable hook:

export const useScrollToActive = (condition?: boolean) => {
  const ref = useRef<HTMLElement>(null);

  useEffect(() => {
    if (condition && ref?.current) {
      activeItemRef.current.scrollIntoView({
        behavior: 'smooth',
        block: 'start',
      });
    }
  }, [condition]);

  return ref;
}

and then we get a cleaner logic in here:

export const SecondaryMenuItemComponent = ({
  // ...
}) => {
  // ...
  const activeItemRef = useScrollToActive(isActive);

  // ...
  return (
    <li ref={activeItemRef>
    // ...
  )
}

[weronikaolejniczak]

@ek-so The smooth scrolling when a side panel opens feels like it makes sense.

But for popovers, since the interaction is on hover, the smooth scroll looks a bit weird to me. Personally, I’d make the scroll immediate 🤔 Curious what you think!

[ek-so]

@ek-so The smooth scrolling when a side panel opens feels like it makes sense.

But for popovers, since the interaction is on hover, the smooth scroll looks a bit weird to me. Personally, I’d make the scroll immediate 🤔 Curious what you think!

Thanks @paulinashakirova, @weronikaolejniczak!
I checked out the POC, and I agree with Weronika — scroll animation inside a popover looks a little weird.
However, could we make sure that when we open popover where smth is selected, we still see the selected item straight away (so it's kinda scrolled to the right place already, just without any animation)?

[weronikaolejniczak]

@ek-so @paulinashakirova personally, I would also add a timeout to the smooth scroll for the side panel. It could be 50 ms. I think if the side panel opens and the smooth scroll starts immediately, it'll be too much. LMK!

[ek-so]

@ek-so @paulinashakirova personally, I would also add a timeout to the smooth scroll for the side panel. It could be 50 ms. I think if the side panel opens and the smooth scroll starts immediately, it'll be too much. LMK!

I agree that the animation itself might feel smoother, but I would not add delays here tbh. My worry is that in this case it might feel like a slowly working system. And now it is smooth and quick at the same time.

[paulinashakirova]

@ek-so @weronikaolejniczak
So I am not sure if we are going to use smooth scrolling in the end, but I currently updated the code for the behaviour when user hovers over the popup and it is already scrolled to visibility.
What do you think?
Should I change it back to smooth scrolling?

Screen.Recording.2025-09-12.at.18.24.54.mov

[weronikaolejniczak]

@paulinashakirova I think this is absolutely fine.

[weronikaolejniczak]

nit:

Could you move this to the hooks folder? Also, it might be nice to add a JSDoc comment to explain the hooks purpose, the args it accepts and what it returns 😄

[paulinashakirova]

Thank you for suggestions! 😊
I can absolutely move to the hooks folder.
I was actually looking at /popover folder next to "mine", and saw hook components side by side, so I thought this is how we should do, but hooks makes sense even more.

And added JSDoc comment ✅

[weronikaolejniczak]

@paulinashakirova If the use_scroll_to_active is used only inside the secondary_menu then we can leave it there. BUT it's so generic, it doesn't have to do with the secondary menu at all, that it's better placed inside that top-level hooks folder. I trust your judgement 😄 Thanks for adding the JSDoc!

[paulinashakirova]

You are right - mine is more generic, whereas popover is in the name of each hooks in that subfolder. 🙏🏻

[ek-so]

@paulinashakirova @weronikaolejniczak I've been playing around for a while with those 2 options, and I came to a conclusion that keeping behavior: "smooth" is still better, because it gives the user a little bit more context of how they got here, and that THERE IS a scroll and other options in the list. Sometimes this might be important. Whereas this feeling of "too much scroll" simply comes from the fact that we are testing the nav, and thus intentionally try to see this scroll again and again :)

However, there are a couple of issues that seem to be independent from scroll behavior.

1. Some items that are placed approx. in the middle, become not visible when I choose them (e.g. Cases in Stack mgmt) — I assume, the scrolling position count doesn't work in these cases?
2. When I choose Advanced setting, something weird happens: first, content gets scrolled together with the menu; second — the menu changes it's right positioning and appears on top of the item 😐

Could you pls look at those?

[paulinashakirova]

@ek-so I reverted the scroll behaviour to be smooth, and also before the element scrolled into view, i tried to align to the most top position available, but now changed to minimal scroll distance, so if it appears from below it will stop at the bottom.
This should fix first concern.
As for the second concern - I couldn't reproduce...
Are you using Chrome for testing?
Could you please try again with my latest changes in case the bug is still present?

Behaviour with popover

Screen.Recording.2025-09-17.at.13.27.39.mov

Behaviour with side panel

Screen.Recording.2025-09-17.at.13.39.08.mov

[weronikaolejniczak]

@paulinashakirova secondary panel is used both in the popover and the side panel. It might be worth to test how the scrolling behaves with the side panel.

Otherwise, looks good to me! 🟢 Amazing work!

[paulinashakirova]

@paulinashakirova secondary panel is used both in the popover and the side panel. It might be worth to test how the scrolling behaves with the side panel.

Otherwise, looks good to me! 🟢 Amazing work!

I updated my previous comment with a screen recording for the side panel.
Could you check it please as well? 😊

[weronikaolejniczak]

Let's wait for Kate's approve but to me it's 👌🏻 👩🏻‍🍳

[ek-so]

Thanks Paulina! Lgtm.

[weronikaolejniczak]

I wrote a comment too soon but actually everything is correct here 🟢 Thanks for adding this!

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 8852275

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
core	562	563	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
core	131.2KB	131.4KB	+167.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	511.3KB	511.3KB	+3.0B

History

• 💔 Build #340470 failed ec16718
• 💔 Build #340318 failed 2726f65
• 💚 Build #338901 succeeded e9fb632
• 💚 Build #337709 succeeded 9a8a5a9

cc @paulinashakirova