Ok, that's a bug. I created an issue to track it, https://github.com/phronmophobic/membrane/issues/70. The make-node protocol is a little half-baked at the moment. The idea is to be able to programmatically traverse and edit an element tree without having to know about all of the different element types. However, I'm not sure how well that works in practice and I haven't used since I added it. I would love to hear more about your use case. Still trying to figure out what make-node should look like and how it should be used.

I'm using it, it seems to be working ok for now

It basically patches over not knowing whether you have a drawable or drawables right, but one thought I had was that it might be unnecessary to ever expect drawables, since vectors are valid components maybe it could just always accept a single drawable, I dunno if that messes up the data model in a different way

I used it in combination with children to implement a walk function that added logging decorations to debug the event flow

oh, interesting.

That's pretty neat.

I've also removed all the component stuff and I'm using atoms and subscriptions to do a more primitive form of data passing

I just spent too much time struggling to understand precisely what was happening with all the refs

> but one thought I had was that it might be unnecessary to ever expect drawables, since vectors are valid components maybe it could just always accept a single drawable, I dunno if that messes up the data model in a different way Yea, that could be true. I've also been considering whether sequences should be treated as valid elements similar to vectors.

I considered extending to maps

Just with the vals, but the keys would be useful for manipulating/reading the tree

> I just spent too much time struggling to understand precisely what was happening with all the refs Yea, you're not the only one. I definitely think membrane.component could have better explanations and be simpler to use, but I haven't quite figured it out.

I'm also happy to support other state management solutions.

I mean component isn't enforced, I still use the top level one. The hard part is if you want to use existing defui components, so the actual work was taking apart textarea and reimplementing it

I know that I could have found the right paths and refs to pass, then written my own thing to handle the intents and push them into my own stare

State

But I figured I might as well just write my own and understand it

Yea, hopefully the component stuff is completely optional. If you run into any problems ignoring component stuff, it would be good to know.

The top-level-ui thing I haven't tried to remove but I think that might be some work, I wonder if the logic in it could be outside component

Actually I had to clone it and patch it to be able to do focus, maybe there was a cleaner way but I just updated an atom to clear focus when no intents from a click

There's some stuff that probably makes sense to keep in component, but I do think top-level-ui does too many things and could be broken into simpler pieces.

There's also some logic in some of the backends that should probably be a simple piece that's composed with top-level-ui (eg. copy/cut/paste).