Persistence + independent layout storage

[benkeen]

Hey! Great project, I've used it for years on my project here. Terrific to see the recent updates, I'm just updating to v3 now.

A couple of feature requests around persistence:

• option for usePersistence() to store the horizontal/vertical layouts independently. I hoped that by supplying a different key, it would do that - but I'm finding that the values are used for both.
• accommodate different browser dimensions when loading the sizes from usePersistence state; i.e. recalculate the values on first load to adjust the relative sizes. I'm finding that in certain scenarios (e.g. saving the dimensions with a large browser, closing the page and re-opening with a much smaller browser window) the persisted values are quite inaccurate and cause the panels to be initially incorrectly placed. Perhaps storing all the values in relative percentage values? Or having an upfront recalculation on first render. Not sure.

I can work around both of these with a controlled component and doing a little math on my end, but it'd be nice for it to handle it all out the box.

Anyway, thanks again - great project.

[tomkp]

Always great to see projects that use this 👍 - I'll take a look at this now...

[tomkp]

Feature Request 1: Independent Layout Storage

This should already work with the current API. Each usePersistence call is independent, so you can use separate hooks for horizontal and vertical layouts:

function App() {
  const [hSizes, setHSizes] = usePersistence({ key: 'layout-horizontal' });
  const [vSizes, setVSizes] = usePersistence({ key: 'layout-vertical' });

  return (
    <SplitPane direction="horizontal" onResize={setHSizes}>
      <Pane size={hSizes[0]}>
        <SplitPane direction="vertical" onResize={setVSizes}>
          <Pane size={vSizes[0]}>Top</Pane>
          <Pane size={vSizes[1]}>Bottom</Pane>
        </SplitPane>
      </Pane>
      <Pane size={hSizes[1]}>Right</Pane>
    </SplitPane>
  );
}

Each hook instance stores its sizes under its own key, completely independently. If you're seeing values "apply to both orientations," it might be that the same state is being passed to both SplitPanes somewhere. Happy to help debug if you can share a minimal reproduction.

Feature Request 2: Browser Dimension Adaptation

This is a valid concern. The current implementation stores absolute pixel values, which can become invalid when the browser window size changes significantly between sessions.

A few options to consider:

1. Percentage-based storage - We could add an option to store percentages instead of pixels. This would require passing the container size to the hook, adding some complexity.

2. Ratio storage - Store the ratio between panes (e.g., [0.4, 0.6]) rather than absolute sizes. Similar to percentages but normalized.

3. Validation on load - Add a callback to validate/transform sizes on load, allowing users to clamp or adjust values based on current dimensions.

4. Keep it simple - The current SplitPane already handles proportional resizing when the container changes during a session. The issue is only on initial load. Users who need this can build it with controlled components:

function App() {
  const containerRef = useRef<HTMLDivElement>(null);
  const [sizes, setSizes] = usePersistence({ key: 'layout' });
  
  // Validate sizes against container on mount
  useEffect(() => {
    if (containerRef.current && sizes.length > 0) {
      const containerWidth = containerRef.current.offsetWidth;
      const total = sizes.reduce((a, b) => a + b, 0);
      if (total > containerWidth) {
        // Scale down proportionally
        const scale = containerWidth / total;
        setSizes(sizes.map(s => s * scale));
      }
    }
  }, []);

  return (
    <div ref={containerRef}>
      <SplitPane onResize={setSizes}>...</SplitPane>
    </div>
  );
}

I'm leaning toward keeping the hook simple and letting users handle validation if needed, but open to adding a mode: 'percentage' | 'pixels' option if there's enough demand. What do you think?

[benkeen]

Thanks so much for your help!

Good call on using usePerformance twice - doh! Should've thought of that. I'll try that out with the controlled component fix from that other issue (thanks for that) - but that should certainly work.

For the second one, as a consumer I like the idea of a percentage mode, because it would work in all cases without any additional code. That seems pretty clean to me. But... I could well imagine a scenario where people use "percentage" to get around the browser resize issue, but still want get the exact pixel value too. Altering the onResize method signature to return both pixels + percentages is sort of tempting, but feels non-normalized and wouldn't be backward compatible. Perhaps in this case, requiring them to do the math to determine the pixel value from the percentage would be ok. But for future major releases, certainly worth thinking about.