4 ms·

I should maybe give solid a fair shake again, I don't think I got "Reactivity" or the signals stuff properly explained to me and got frustrated that something I

I should maybe give solid a fair shake again, I don't think I got "Reactivity" or the signals stuff properly explained to me and got frustrated that something I could easily, competently do with react+setState just fell over or bugged out in their little demo / codepen (huge props to having that demo/codepen though, much nicer UX for a dev trying to learn than just documentation) But that Imba thing? I rewrote this and the kindest I can say is.... I don't see the value add? Learning it isn't going to be transferable?

slmjkdbtl 4y ago
Reactivity is magnitudes simpler and more performant than react style state diffing, it's also much harder to write bad performance code because there's no react style re-rendering. The basic form of signal can be just function signal(value) { const subs = [] return { get: () => value, set: (newValue) => { value = newValue subs.forEach(f => f(value)) }, sub: (action) => subs.push(action), } } For building UI, when the component constructor sees a signal object being passed either to a property / children they'll automatically subscribe to the updates of this signal, and update the HTML property / children when there's an update to the signaled value. With this there's almost no overhead beyond setting those stuff yourself with vanilla JS (except for list updates, those still require diffing). Of course Solid's signal implementation is much more robust and have some very mild magic to make the UX better, but the core concept is really simple. Read about Solid's implementation here https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p https://dev.to/ryansolid/building-a-reactive-library-from-sc...
- sapling-ginger 4y ago
  > there's almost no overhead The runtime has to maintain a graph of those signals tree in memory at all time, no? Compared to React that can throw away the vdom after it finished the render.
  - slmjkdbtl 4y ago
    I don't think there need to be a tree or any data structure signals need to be stored in, as long as those objects are preserved in memory and can be referenced.

slmjkdbtl 4y ago

Reactivity is magnitudes simpler and more performant than react style state diffing, it's also much harder to write bad performance code because there's no react style re-rendering. The basic form of signal can be just function signal(value) { const subs = [] return { get: () => value, set: (newValue) => { value = newValue subs.forEach(f => f(value)) }, sub: (action) => subs.push(action), } } For building UI, when the component constructor sees a signal object being passed either to a property / children they'll automatically subscribe to the updates of this signal, and update the HTML property / children when there's an update to the signaled value. With this there's almost no overhead beyond setting those stuff yourself with vanilla JS (except for list updates, those still require diffing). Of course Solid's signal implementation is much more robust and have some very mild magic to make the UX better, but the core concept is really simple. Read about Solid's implementation here https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p https://dev.to/ryansolid/building-a-reactive-library-from-sc...

sapling-ginger 4y ago
> there's almost no overhead The runtime has to maintain a graph of those signals tree in memory at all time, no? Compared to React that can throw away the vdom after it finished the render.
- slmjkdbtl 4y ago
  I don't think there need to be a tree or any data structure signals need to be stored in, as long as those objects are preserved in memory and can be referenced.