What is the best practice for positioning inline edit overlays when the target element is outside the viewport?

[lixiaoyan]

For inline editing patterns (similar to the editable cells in S2 TableView), S2's current approach is to display a popover positioned directly over the target element. We've adopted a similar strategy for some of our components, but we've run into an issue: if the editable element is outside the viewport, the popover also renders off-screen and remains invisible. From the user's perspective, the page simply becomes unresponsive.

This typically occurs when, for example, a new row is added and immediately transitions into edit mode. Since the new row and the popover are rendered within the exact same render cycle, there isn't a suitable lifecycle timing to scroll the page and bring the element into view before the popup appears.

Are there any best practices or recommended workarounds for resolving this type of issue?

(Note: Our implementation differs slightly—we use a dialog instead of a popover, along with custom positioning logic.)

[snowystinger]

We haven't come across this yet, would you be willing to put together a stackblitz showing it?

Otherwise, you could always delay by a render. Or measure based on a row before/after that you know exists?

[MILLERMARRU]

Since S2's own TableView editable-cell popover doesn't seem to hit this in practice, I went looking at how react-aria itself solves the "target might be off-screen when we need to position something against it" problem elsewhere, and there's already a private-but-exported utility for exactly this: scrollIntoViewport from react-aria/private/utils/scrollIntoView (re-exported via @react-aria/utils).

It's used throughout the collection hooks (useGridCell, useGridListItem, useDateSegment, useCalendarCell) for the same underlying problem: focus/positioning logic needs the target to actually be in the viewport before it measures anything. The important part is how it's called, synchronously, right next to focusSafely, inside the event handler/layout phase, not deferred to a later render:

focusSafely(focusable);
scrollIntoViewport(focusable, {containingElement: getScrollParent(ref.current)});

It compares getBoundingClientRect() before/after an internal scrollIntoView({block: 'nearest'}) call and only escalates to containingElement.scrollIntoView({block: 'center'}) if the element actually moved, so it's cheap to call unconditionally.

For your case, the reason "delay by a render" feels necessary is probably ordering: whatever computes your dialog's position (measuring the target's getBoundingClientRect()) is running in the same commit as the row's mount, before the scroll has happened, so it captures a stale/off-screen rect. Since useLayoutEffects fire bottom-up in commit order and before paint, you don't actually need an extra render, you need the scroll to happen in a layout effect that's guaranteed to run before whatever measures the target for positioning. Concretely: put scrollIntoViewport(rowRef.current, {containingElement: scrollParentRef.current}) in a useLayoutEffect on the new row itself (child), and make sure your dialog's positioning effect (parent, or triggered after) reads the target's rect only after that. Since it's all inside the layout phase, nothing paints until it's done, so there's no visible jump, no "delay by a render" needed, no flash of the popover in the wrong place.

If your custom positioning logic currently measures the target's rect at open-time from useState/useMemo during render instead of a layout effect, that's the more likely actual bug, that measurement would run before the DOM node has committed at all in a same-cycle add-and-edit scenario.