Great article. Re-using nodes is definitely a thing, but it isn't always a generalizable optimization. At times in the past it has been stressed how dangerous it is to do so. It isn't always dangerous but it is definitely opt in. Cloning nodes might not always be beneficial but it is something we can just do.
I think the biggest thing that makes Voby's DX not suffer and something that I didn't consider early on is the unwrap function. I findisSignal is insufferable from an authoring standpoint if you need to check everywhere. This was the life building re-usable components/directives in Knockout. But simply having a function (and all JSX bindings) be like we don't care we handle both simply by accessing it with a special function alleviates that a lot.
Also, your points on spreads are dead on. It was something I tried optimizing early on and I was mistaken. This has been on the list for a while and each release we've been making incremental improvements to spread and will finally be addressed in Solid 1.6. Which reminds me, in Voby are prop spreads dynamic on components? Like if the properties on a components change dynamically (ie new properties added, others removed). Can the props object itself be a signal in a sense?
Regarding unwrapping I agree that $$ is pretty handy, potentially that has an hidden problem though, which is: if I write $$(count) what am I supposed to name the variable that I assign that to? Which sounds silly but I found this to be a real annoyance. When that's a problem I use another function, useResolved, which solves the issue though the code becomes a little weird, it feels like a different take on dependency arrays, maybe it's something similar to what you did in the Knockout days. FWIW it looks like I've called $$ 307 times and useResolved 37 times in my current repo.
Can the props object itself be a signal in a sense?
I've never thought about this π€ the object can't be a signal, I guess one would need to sort of unpack it manually. I don't know if object spreads can be intercepted somehow in JS, if they can potentially the library could do the unpacking for you automatically, I should think about that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article. Re-using nodes is definitely a thing, but it isn't always a generalizable optimization. At times in the past it has been stressed how dangerous it is to do so. It isn't always dangerous but it is definitely opt in. Cloning nodes might not always be beneficial but it is something we can just do.
I think the biggest thing that makes Voby's DX not suffer and something that I didn't consider early on is the unwrap function. I find
isSignalis insufferable from an authoring standpoint if you need to check everywhere. This was the life building re-usable components/directives in Knockout. But simply having a function (and all JSX bindings) be like we don't care we handle both simply by accessing it with a special function alleviates that a lot.Also, your points on spreads are dead on. It was something I tried optimizing early on and I was mistaken. This has been on the list for a while and each release we've been making incremental improvements to spread and will finally be addressed in Solid 1.6. Which reminds me, in Voby are prop spreads dynamic on components? Like if the properties on a components change dynamically (ie new properties added, others removed). Can the props object itself be a signal in a sense?
Thank you π
I agree 100% regarding re-using nodes.
Regarding unwrapping I agree that
$$is pretty handy, potentially that has an hidden problem though, which is: if I write$$(count)what am I supposed to name the variable that I assign that to? Which sounds silly but I found this to be a real annoyance. When that's a problem I use another function,useResolved, which solves the issue though the code becomes a little weird, it feels like a different take on dependency arrays, maybe it's something similar to what you did in the Knockout days. FWIW it looks like I've called$$307 times anduseResolved37 times in my current repo.I've never thought about this π€ the object can't be a signal, I guess one would need to sort of unpack it manually. I don't know if object spreads can be intercepted somehow in JS, if they can potentially the library could do the unpacking for you automatically, I should think about that.