Great stream, I followed all the way through and it helps a ton in helping me iron out a model for how solid works and the challenges you tackled. Thanks!
What would happen if you did not cleanup the dependencies array for each signal? Is this technique for being able to create effective memos or is there something else?
You could oversubscribe with conditionals. It would listen to whatever it ever listened to even if that dependency didn't matter anymore. This ensures the least possible execution. There has been some research into treating deps as static until changed. Sort of like the way under the hood V8 marks things as monomorphic vs polymorphic. If deps never change don't bother releasing them. And if they do deopt it to always clean. This could be a cool optimization to try.
@@ryansolid You talked in this stream how those calculations are relatively cheap. I am trying to figure out how you can measure the added value of this kind of optimisations (along with memos). It adds complexity to the framework primitives and changes the DX. When exactly it becomes crucial?
@@maorben3313 I do a lot microbenchmarking. There is a lot more code complexity and some size which is why I've shied away from some optimizations. There are a couple things like that. I've implemented and was like not enough meaningful measured impact. Like show up in a reactive benchmark but not a DOM one. The core cleanup mechanism though is more about correctness and execution guarentees.
@@ryansolid I guess my question is if it is not enough to bind subscribers to parent nodes and cleanup on unMount, use textNodes previous values and keyed lists as the memoization guard, and count on js being fast enough to calculate all derivations without worrying about memos and cleanups at all. Treating the renderer as the bottleneck in some sense?
@@maorben3313 We often don't need Memos and I often tell people not to bother just use a function. Because like unlike React we don't need them for stable values. We definitely don't want to store state in the DOM as reading it can be expensive. We do use Memos internally in the renderer to store those lists to diff. Memos aren't only memos I suppose but always points at which re-calculation can spawn so they serve often as boundaries.
56:43 You probably would wrap 63 and 64 on untrack in a try {} finally {} block though, right? Or you will lose the entire context of the current reactive cycle
For someone who is currently creating a frontend framework this is gold! Especially the "don't memo everything part"🏅
Great stream, I followed all the way through and it helps a ton in helping me iron out a model for how solid works and the challenges you tackled. Thanks!
Thanks Ryan I had so much curiosity about this topic, now I feel I get the basics
This stream demystified a lot of concepts. Thanks!
Thank you so much for posting this! It honestly opened up my mind :O 🤯 guess I've got an interest in frontend framework architecture now :P cheers! ✌️
What would happen if you did not cleanup the dependencies array for each signal? Is this technique for being able to create effective memos or is there something else?
You could oversubscribe with conditionals. It would listen to whatever it ever listened to even if that dependency didn't matter anymore. This ensures the least possible execution.
There has been some research into treating deps as static until changed. Sort of like the way under the hood V8 marks things as monomorphic vs polymorphic. If deps never change don't bother releasing them. And if they do deopt it to always clean. This could be a cool optimization to try.
@@ryansolid You talked in this stream how those calculations are relatively cheap. I am trying to figure out how you can measure the added value of this kind of optimisations (along with memos). It adds complexity to the framework primitives and changes the DX. When exactly it becomes crucial?
@@maorben3313 I do a lot microbenchmarking. There is a lot more code complexity and some size which is why I've shied away from some optimizations. There are a couple things like that. I've implemented and was like not enough meaningful measured impact. Like show up in a reactive benchmark but not a DOM one.
The core cleanup mechanism though is more about correctness and execution guarentees.
@@ryansolid I guess my question is if it is not enough to bind subscribers to parent nodes and cleanup on unMount, use textNodes previous values and keyed lists as the memoization guard, and count on js being fast enough to calculate all derivations without worrying about memos and cleanups at all. Treating the renderer as the bottleneck in some sense?
@@maorben3313 We often don't need Memos and I often tell people not to bother just use a function. Because like unlike React we don't need them for stable values.
We definitely don't want to store state in the DOM as reading it can be expensive. We do use Memos internally in the renderer to store those lists to diff. Memos aren't only memos I suppose but always points at which re-calculation can spawn so they serve often as boundaries.
56:43 You probably would wrap 63 and 64 on untrack in a try {} finally {} block though, right? Or you will lose the entire context of the current reactive cycle
Yeah its like that today. Something I had missed at the time of the stream over a year ago.
I figured you knew, but wanted to call it out for future viewers. Thanks for the amazing content