feat: Split GroupTree into GroupTreePlot-component and settings

[jorgenherje]

Split previous /package/group-tree into a view-component, /package/group-tree-plot, which is independent of redux and mui. The old GroupTree-component placed in python/src/components, for usage in Dash, now has a lot of the code from the old /package/group-tree

Thereby the new group-tree-plot can be used directly in Webviz NextGen.

Removed package: package/group-tree
New package: package/group-tree-plot

---

Closes: equinor/webviz#461

[hkfb]

A good improvement would be to use Storybook argTypes for the date, edge and nodes. Eg. the date could be represented by a slider or datepicker, and the edges and nodes by an enum (https://storybook.js.org/docs/api/arg-types#controltype). This would make it easier to test this component.

[jorgenherje]

A fair point, but I all these values depend on structure of datedTrees, edgeMetadataList and nodeMetadataList. If these are changed, the validity of selectedDateTime, selectedEdgeKey and selectedNodeKey can change (i.e. the options for valid selections).

Thereby I'll stick to the basic type of string, with a descriptive comment.

As these are props of type string, I'm afraid the user will not see the connection of selected dates/keys and the actual set of possible keys/dates in the datedTrees and metadata lists.

Unless I misunderstand? If so it would be nice with an example of implementation you think of, to ensure we are on the same page.

[hkfb]

I'm not sure if we're talking about the same thing. Not proposing to change the component if that's what you mean.

Just to make the story easier to test you could enhance the controls in the story itself. As an example, you could add something like this:

Default.argTypes = {
  selectedDateTime: {
    control: "date"
  }
  selectedEdgeKey: {
    control: "select", options: getKeys(edgeMetadataList)
  }
}

It's just a suggestion. You can resolve.

[jorgenherje]

@hkfb

Probably not 100% aligned initially. I did not think you proposed to change the component, but I was a bit unsure whether the user will loose sight of how the props actually depend on each other. If adding select where we have a list with preset options, the options might become invalid when the user interacts with the data.

I've tested your suggestion and it looks very good, but it seems like the options for selectedEdgeKey and selectedNodeKey does not update if the edgeMetdataList and nodeMetadataList keys are changed. Is it possible to make these be updated after the user changes the keys in the lists? This is one of the examples where the user might change in the ...MetadataList- or datedTrees-prop and have invalid options in the selects.

See commit Bug fix and adjust storybook for testing of the storybook adjustment.

[hkfb]

Ok, got your point. If you still want to have a try there are some solutions using the useArgs hook here:

https://stackoverflow.com/questions/63708208/how-to-dynamically-mutate-args-in-storybook-v6-from-the-components-action

https://medium.com/urbandataanalytics/changing-args-values-state-in-storybook-without-usestate-hook-15cc096716f7

You can resolve.

[hkfb]

Approved with one suggestion in the comments 👍

[hkfb]

Btw, perhaps we should use the feat prefix, since normally refactor won't trigger a release.

[rubenthoms]

LGTM, good work! Some comments, up to you to adjust or not.

[hkfb]

🎉 This issue has been resolved in version [email protected] 🎉

The release is available on GitHub release

[hkfb]

🎉 This issue has been resolved in version [email protected] 🎉

The release is available on GitHub release

[hkfb]

🎉 This issue has been resolved in version [email protected] 🎉

The release is available on GitHub release

[hkfb]

🎉 This issue has been resolved in version [email protected] 🎉

The release is available on GitHub release

[hkfb]

🎉 This issue has been resolved in version [email protected] 🎉

The release is available on GitHub release