DEV Community

loading...

Component hierarchy data model and inspector UI

Jeff Lindsay
Indie maker of many things. Helped pioneer SHDH, webhooks, Hacker Dojo, TIGSource, OpenStack, JWT, Twilio, Docker, Dokku, all incidental. Follow your curiosity
・2 min read

Continuing on my TreeView prototype, I've been experimenting with the actual data model of the Nodes behind the TreeView. Before we had a TreeNode, but this is actually a representation of a more complex Node that has its own tree structure. So I implemented that data model and tied changes in the UI to changes to that data model, since it then creates a TreeNode representation the TreeView component uses.

I also had to make sure this was a serializable data structure. This led to a few iterations but what I have now is very simple. I almost had a separate struct to model how the data would be serialized, but then I'd have three different views of a Node.

I also brought in Components. First as part of the data model and getting them to serialize correctly. This was tricky because a component can be nearly any struct and we want to unserialize into the right type. So we had to wrap it in a data structure that has the type name, which we can feed into our sort of component factory to get a new instance and unmarshal into that. I also used the MarshalJSON and UnmarshalJSON interfaces for the first time, letting me partially unmarshal a slightly different representation to get the type name, then unmarhsal the rest after making a component instance.

Then I was ready to recreate the property inspector the original prototype had. I wanted to recreate this with UI components instead of wrapping that jQuery library from before. This way I could actually dogfood the UI framework more. I ran into a few issues that I was able to fix or workaround, but it is working to the point of listing the field names of the Node and any components it has.

It's been exciting to be able to use my WASM UI framework and things mostly just work.

Discussion (0)