Yeah, this is what I'm talking about - a fuller explanation would require more text. :)
The question is what you're doing with z. As long as you're also adding and removing your hypothetical panels in turn with bind, you're good:
div {class: 'container'}, bind -> [
if show.get()
div {class: 'z'}, bind -> x.get() + y.get()
else
div {class: 'nothing'}
]
The question is what happens at the top level or when you want to break out and do your own thing. We don't have the luxury of weak refs in JS, and as a result it's less forgiving if you do "silly" things like create binds that go nowhere and that you don't want to keep. But even with weak references, one can't tell if you added a bind only to subscribe a console.log caller to its changes, save to localStorage, or some other side effect that you
do want to keep. In any case, it's incumbent on us to fully document what "silly" means, include simple-to-use API calls to capture and dispose entire subgraphs (for when you want to do your own thing manually), and provide good debugging introspection tools for finding these `bind`s to nowhere, in case you really don't want them lingering around.
We've also been bouncing around ideas for reversing the reference DAG and having cells named by the reversed paths through the DAG, which we may experiment with. You then get to deal with the converse problem of manually needing to hold references to the sinks in the DAG. In any case, we're very open to learning from how things play out in practice, and shape the direction of the library accordingly.