Trying to understand roots and disposers

[tommaisey]

Hi there, I'm trying to understand how Solid.js works at a deep level, and I'm not quite understanding the concept of createRoot and the disposer argument taken by the function it receives.

I have followed the excellent explanation Building A Reactive Library From Scratch, but it doesn't go as far as these concepts.

Is the concept of a disposer required because 'global' references are kept to reactive graphs? If your library had no createMemo or similar, would roots and disposers be necessary? Or do they serve other purposes too?

My current guess is that 'glitches' are only possible because of createMemo. So its inclusion results in the requirement for a more advanced 'two pass' traversal of a reactive graph, to prevent glitches. And this requires an in-memory representation of the graph, creating the need for 'roots' and disposers.

Note: I'm not actually even a javascript developer! Though I have the basics down. I'm working on a native platform that's quite analagous to a browser, but it's using Lua as its scripting language. Our API is close enough to a 'DOM' that I'm curious whether I can create a reactive library for it, and of all the concepts I've tried so far, the principles of Solid seem to fit most seamlessly, hence my interest.

If you know of other resources that explain this more deeply, I've love to see them (my google foo is failing at this point).

[atk]

In the article you mentioned, you learned how to automatically subscribe side effects to your reactive state by making the read access also a subscription. Dispose simply removes the subscriptions, so no calls into unused side effects remains. At least, that's my understanding.

[ryansolid]

Yeah the createRoot is about automatic disposal which isn't relevant to most reactive systems unless you are nesting. This doesn't have much of a behavior consequence under normal execution. It's just makes building hierarchies work better. I do talk about it a bit in here which I consider a sequel to the other article: https://indepth.dev/posts/1289/solidjs-reactivity-to-rendering.

Basically every computation also keeps track of computations created during it's execution so it can release on re-executing. However, top level we need something to manage all top level computations. That being said top level could conceptually never release until the document is unloaded. The other usage is so that children can be disposed independently of their parent lifecycle. Since we automatically free children on parent re-execution we need a way to opt out of that and createRoot does that.

Recently we've actually used this too for synchronous scheduling. Since it wraps the whole initial execution we use this as a way to run user effects at the end of all updates. This lets us run things after rendering etc.

[tommaisey]

I think I'm beginning to get my head around this a little more now. Of course a side-effect isn't really 'attached' to a component in any way, so even if the component was destroyed, the side-effect function would continue to exist, still subscribed to any signals it used. And if a side-effect is used to update some DOM node I guess that even after the node is removed from the page, it would hang around as a zombie, because it's captured into the side-effect's closure?

Thanks for your replies! They are certainly pointing me towards a better understanding.

[damianstasik]

And if a side-effect is used to update some DOM node I guess that even after the node is removed from the page, it would hang around as a zombie, because it's captured into the side-effect's closure?

You can use onCleanup to clean up listeners/etc. to make sure it won't happen when the node is unmounted.