Grafana/UI: Add new Splitter component

[torkelo]

This brings a component @kaydelaney developed over from the scenes lib. As we need it in core directly (and not only through scenes SplitLayout).

•  Refactors component a bit moving state logic out to a hook
•  Removes unused props
• Use our relatively new shared drag handle styles
•  Adds storybook story
•  Add dragPosition prop so we can have drag handles on the edge in panel edit (saves some space and we then use same UX pattern as with the drag handle in the drawer that is also on the edge)
• Storybook docs

General-Layout-Splitter---Basic-.-Storybook.mp4

[ashharrison90]

this looks great and is really gonna help with our consistency 🚀

Add dragPosition prop so we can have drag handles on the edge in panel edit (saves some space and we then use same UX pattern as with the drag handle in the drawer that is also on the edge)

my potentially controversial UX opinion... i think we should always indent our drag handles and not have them on the edge. something like:

	default	onHover
explore
drawer

[torkelo]

@ashharrison90 not sure, looks very strange with a drag handle floating inside the box. Feels much more intuitive with it the edge (and that way it does not conflict/overlap the content). We can tweak the drag handle styling maybe (in the future) to add some kind of grip bars to make it more noticeable or tweak the background.

Did check with UX (patrick) and agree that having on the edge is best, like we do for drawer and explore drawer. For panel edit the options pane there is no room to have it inside the box

[torkelo]

@ashharrison90 here is having it inside the panel edit options pane, not great :)

[ashharrison90]

@torkelo yeah in the panel edit case i'd still have it in the gap tbh. that feels like a slightly different use case to drawers anyway (resizing 2 panes vs. resizing one edge)

the main reason for me thinking that is that other drag handle examples are indented, e.g. slack on mobile:

but that might be more of a mobile pattern 🤔
either way consistency is king so happy for anything as long it helps with that 😄

[torkelo]

@ashharrison90 slack on desktop it's on the edge (without any drag handle)

[torkelo]

@ashharrison90 pushed storybook docs, and added some prop docs and simplified it a bit more. Think this is ready

[kaydelaney]

Looks good!

[ashharrison90]

Suggested change

	verticalOffset = '0';
	horizontalOffset = '0';
	verticalOffset = '0%';
	horizontalOffset = '0%';

[torkelo]

fixed

[ashharrison90]

this is a lot of returned "things". could we instead group some of them into one thing like splitterProps that can then be spread onto the splitter element? i'm mostly thinking about the interaction stuff (onPointer, onKey, onBlur, etc.), since they all have to go on the same element anyway

[ashharrison90]

you could also return the tabIndex, associated aria-value* attributes and role stuff as part of the splitterProps as well if you pass through the initialSize? that way you wouldn't have to manipulate the dom directly in the hook to change ariaValueNow

[torkelo]

@ashharrison90 I moved most to a splitterProps and got rid of a few others, I did not like adding role, aria props tabIndex etc, because then I basically have move everything to the hook and there i no nothing in the markup generation left so the separation between callback / static logic and markup rendering becomes lost.

I agree if useSplitter was designed to be used outside this component is should probably return all props, but here it just a way to separate all the callbacks from the rendering

[ashharrison90]

i think we can simplify our types a lot here if we restrict this to only allow an element to be passed (and not null). then our return type is always just

{ minWidth, maxWidth, minHeight, maxHeight }

and we just gate every use of measureElement behind an if statement, like

if (firstPaneRef.current) {
  const dim = measureElement(firstPaneRef.current);
  ...
}

this will also allow us to remove all(?) of the ! operators. maybe slightly more lines, but imo more readable and type-safe 😎

[torkelo]

good suggestion! updated, had to add a lot if statements though :)

[ashharrison90]

can remove the type assertion - otherwise lgtm 👍

[ashharrison90]

can remove this type assertion 🥳

[torkelo]

ah, of course :)