feat(hooks): add useLayoutState

[pinussilvestrus]

Proposal: This adds a useLayoutState hook to persist state inside the global LayoutContext. The LayoutContext can be used to persist state for components that might not be rendered sometimes (example groups), but we want to keep.

const groupId = 'general';

const [ open, setOpen ] = useLayoutState(
  [ 'groups', id, 'open' ],
  false
);

setOpen(true);

Potentially it would also be possible to persist this layout state outside of the application (e.g. the Camunda Modeler), via propertiesPanel.layoutChanged + the layoutConfig parameter.

Closes #98

[nikku]

To understand the overall direction we're heading UI-wise first: Layout state (collapsed/expanded) is sticky across elements: Section foo is open on element A, it will also be open on element B, if it exists there.

This PR adds the foundations to ensure that if element B does not contain foo the section is still opened in A once the user switches back?

[pinussilvestrus]

To understand the overall direction we're heading UI-wise first: Layout state (collapsed/expanded) is sticky across elements: Section foo is open on element A, it will also be open on element B, if it exists there.

This PR adds the foundations to ensure that if element B does not contain foo the section is still opened in A once the user switches back?

Exactly!

[pinussilvestrus]

Adding @andreasgeier for a design review (proper behavior). Command to try it out

npx @bpmn-io/sr bpmn-io/bpmn-properties-panel#main -l bpmn-io/properties-panel#98-keep-group-state -c 'npm run start:platform'

[andreasgeier]

The root level (sections/groups) works exactly as expected - great work!

But we have inconsistency on other levels. For instance, a user creates 3 input variables and some of them are in opened state. If the input group is closed and re-opened without switching the element, the variables keep their state but when switching the element selection, all variables within the input section are closed.

@pinussilvestrus Let me know how to proceed here. Having this behavior available on the root is already a great improvement. We can discuss if we want to handle other levels as well (and how) or tackling it in another PR or ignore it for now.

[pinussilvestrus]

I think we have a good chance to use the same strategy for other components as well (as sketched for list items in #90 (comment)).

I think this PR is a good starting point how to tackle a similar set of problems (persisting component state during a session). If we agree on something (+ merge) we can freely do the same for other parts (as mentioned in #99 (comment)).

[andreasgeier]

Based on our discussion that this solution works as expected for groups and the behavior of the sub-levels are considered in another issue, I can approve this.

[barmac]

🤯

[barmac]

LGTM

[barmac]

Really cool stuff.

[pinussilvestrus]

Let's roll this out for other components as well as a next step (example: #90).