Layout shift when using defaultSize

[cloudkite]

Thanks for the great library! ❤️

I recently ran into and issue with using defaultSize and SSR. It looks like defaultSize is not read/used during SSR and therefore causes a layout shift once the client hydrates

Minimal reproduction:
https://stackblitz.com/edit/stackblitz-starters-cz7fruq9?file=src%2Fapp.tsx

[bvaughn]

Ah, this is understandably kind of a confusing behavior, but defaultSize is a prop of the Panel component. Panels get their size information from the parent Group component, because it needs to consider all panels and their various min/max/default size constraints before it can determine how to allocate size between panels. The group can't do that until panels have registered though (which doesn't happen until they've mounted) because the group isn't aware of them yet. And of course, mounting doesn't happen until after they've rendered on the client.

I think you'll need to use the defaultLayout prop on the Group component if you want SSR to work without any flicker. Check the docs for examples of how you can do it with persistent layouts (either for SSR or Server Components).

[bvaughn]

More concretely, for your repro that would mean this change:
https://stackblitz.com/edit/stackblitz-starters-hcwngy3k?file=src%2Fapp.tsx

Note that REM sizes can't really be used for defaults because there's no way to query the document for its root font size from the server. Default layout must be % based.

I've updated the docs to call this out as a foot gun:

Sorry for the confusion. Hope this helps you get the issue resolved, but let me know if not! 😄

[cloudkite]

thanks so much for taking the time to reply!

I found a workaround which works well enough for my usecase. Bit of background I started to look into using defaultSize because one of my panels has a fixed collapsedSize="10rem".
I pass a persisted defaultLayout, however when collapsed it causes bit of jankiness during SSR as it will render as a percentage which can be smaller or bigger than collapsedSize and then when it hydrates it snaps to the collapsedSize.

My workaround is to detect mounting and conditionally render a style override for that panel if it hasnt mounted yet:

#navbar {
  flex-grow: 0 !important;
  flex-shrink: 0 !important;
  flex-basis: 10rem !important;
  width: 10rem !important;
  min-width: 10rem !important;
}

[bvaughn]

I pass a persisted defaultLayout, however when collapsed it causes bit of jankiness during SSR as it will render as a percentage which can be smaller or bigger than collapsedSize and then when it hydrates it snaps to the collapsedSize.

Ah, right. This is an interesting limitation that I had not considered.

My workaround is to detect mounting and conditionally render a style override for that panel if it hasnt mounted yet:

Nice! Any chance you could share the code you used for this? Maybe I can add it to the docs if nothing else.

[cloudkite]

Not sure how useful this code will be as an example as I have a custom persistance format, I store whether the panel is collapsed or not. Without this info the workaround isnt really possible, as during SSR you cant tell from a percentage if the panel should be collapsed or not.

Heres a simplified version anyway

// We persist layout in a custom format this gets mapped to { [id]: number } and passed to group.

export type Layout = { [id: string]:  { size: number; collapsed?: boolean }; };

// wrapper around Resizable panel
export function Panel({
  id,
  defaultSize,
  collapsedSize = "0%",
  style,
  ...props
}: PanelProps) {
  let ctx = use(LayoutContext);
  let panel = ctx.layout[id];
  let mounted = useRef(false);
  let size = panel?.collapsed ? collapsedSize : defaultSize;

  useLayoutEffect(() => {
    mounted.current = true;
  }, []);

  return (
    <>
      {!mounted.current && size && (!panel || panel.collapsed) && (
        <style>
          {stringifyRules(
            {
              [`#${id}`]: {
                flexGrow: 0,
                flexShrink: 0,
                flexBasis: size,
                width: size,
                minWidth: size,
              },
            },
            { important: true },
          )}
        </style>
      )}
      <ResizablePrimitive.Panel
        {...props}
        id={id}
        defaultSize={defaultSize}
        collapsedSize={collapsedSize}
        style={css(style)}
        panelRef={(ref) => ctx.setPanel(id, ref)}
      />
    </>
  );
}

[cloudkite]

Note that REM sizes can't really be used for defaults because there's no way to query the document for its root font size from the server. Default layout must be % based.

Just throwing ideas around, what about if theres no layout info from Group then panels use their defaultSize to set the style, non percentage values are treated as like a fixed panel (ie it outputs rem or px value directly into the style) and percentage ones use flex-grow? This potentially would mean defaultSize works for SSR? In theory this would solve my issue with collapsedSize jankiness as I could skip setting defaultLayout and just use defaultSize to reinstate my persisted layouts and would let me persist in non percentages if I wanted to.

Not sure if thats feasible or maybe its not worth it in terms of added complexity / edge cases.
My workaround seems to work fine for my scenario and I can contain it in my wrapper component so doesnt polute the consumers so not too fussed about it.

[bvaughn]

Thanks for sharing your workaround code.

what about if theres no layout info from Group then panels use their defaultSize to set the style, non percentage values are treated as like a fixed panel (ie it outputs rem or px value directly into the style) and percentage ones use flex-grow?

This is an interesting suggestion. Maybe it would work in many cases 🤔 maybe enough to try supporting it. I'm not sure it would work in every case, in terms of min/max sizes. Probably worth trying out though.

I've filed #695 to follow up.

[bvaughn]

A change to the initial rendering of panels with defaultSize values has shipped in version 4.7.5

See below for details

---

Note

This change is not enough to prevent layout shift entirely in all scenarios, but it should dramatically reduce it.

For example:

<Group>
  <Panel>left</Panel>
  <Panel defaultSize="25%">right</Panel>
</Group>

Because of the way this library works, the eventual panel styles (after hydration) will be:

[left-panel] {
  flex: 75 1 0;
}
[right-panel] {
  flex: 25 1 0;
}

It's possible to server-render the right panel with a style that is compatible with its goal style, but it's less obvious what style the left panel should server-render with. Since neither the left panel nor the parent group know yet about the right panel's default style, the best the left panel can server-render with is the style this library currently uses, meaning:

[left-panel] {
  flex-grow: 1;
}
[right-panel] {
  flex-basis: 25%;
}

The resulting layout will be pretty close to the eventual layout, but it won't be an exact match if the parent group uses the gap style.

The difference can be seen with this reduced HTML example:

<div style="width: 500px">
  <div>Server vs client</div>
  <div style="display: flex; gap: 1rem">
    <div style="background-color: #afa; flex-grow: 1">left</div>
    <div style="background-color: faa; flex-basis: 25%">right</div>
  </div>
  <div style="display: flex; gap: 1rem">
    <div style="background-color: #afa; flex: 75 1 0">left</div>
    <div style="background-color: #faa; flex: 25 1 0">right</div>
  </div>
</div>

The larger the (flex) gap, the more noticeable the shift.

Note

The layout shift shown above only applies to percentage-based sizes. Pixels, ems/rems, and viewport based units do not exhibit this behavior.

This project's server-rendering test harness illustrates the amount of layout shift that occurs with a moderate flex gap style. Though there's still some layout shift, it's a big improvement over the previous behavior.

Before	After
before.mov	demo.mov

---

❤️ → ☕ givebrian.coffee

[cloudkite]

Just tested this out in my app and works great! Can remove my hacky style override 🎉