4 ms·

The one place where signal based fine-grained reactivity still wins are lists. Updating the "done" state of a single todo item nested in a list of todo items s

by spion 2y ago

The one place where signal based fine-grained reactivity still wins are lists. Updating the "done" state of a single todo item nested in a list of todo items still causes an entire list (of possibly hundreds of items) to re-render. In principle you can solve this with fully normalized state shape but in practice things like MobX (especially when combined with SolidJS) still provide the best ergonomics and separation of concerns with very little compromise. I'm however excited to see what kind of DX improvements the compiler can bring to the table. Perhaps someone will have a good idea and we'll get something that's at the level of MobX.

eknkc 2y ago
Ok haven’t tested this but assuming a naive implementation of an array of 1000 items and setting completed: true in one of them by updating the array would trigger 1000 calls to the inner components. If the react compiler is used, 999 of them will return their memoised result. 1 will need to be rendered again. Which has an overhead but is still a huge gain compared to actually creating vnodes and diffing all render results for all items. You are right, in case of fine grained reactivity, this could just trigger a render on the specific item. But for that to work, the framework will need to wire up 1000 subscriptions to prop changes, have proxy objects and shit like that. There is a larger initial overhead for that and the memoisation + brute force approach might be better at the end.
- spion 2y ago
  The setup / overhead is for the initial render, but after that I'd be surprised if O(N) defeats O(1) even with a bit of a bigger constant (given a sufficiently large N). Also, given React Fiber, I doubt that those 1000 calls will simply be function calls - I'd expect plenty of overhead on that end too. Would be interesting to design a realistic benchmark around this. IIRC Michel Weststrate (the author of MobX) had a realistic example based on draggable elements on diagrams, where the diagram link lines needed to be recomputed in realtime as you drag the boxes around. Another realisitc option would be large dashboards made of tables where lots of data updates come in real time.

by spion 2y ago

eknkc 2y ago

Ok haven’t tested this but assuming a naive implementation of an array of 1000 items and setting completed: true in one of them by updating the array would trigger 1000 calls to the inner components. If the react compiler is used, 999 of them will return their memoised result. 1 will need to be rendered again. Which has an overhead but is still a huge gain compared to actually creating vnodes and diffing all render results for all items. You are right, in case of fine grained reactivity, this could just trigger a render on the specific item. But for that to work, the framework will need to wire up 1000 subscriptions to prop changes, have proxy objects and shit like that. There is a larger initial overhead for that and the memoisation + brute force approach might be better at the end.

spion 2y ago
The setup / overhead is for the initial render, but after that I'd be surprised if O(N) defeats O(1) even with a bit of a bigger constant (given a sufficiently large N). Also, given React Fiber, I doubt that those 1000 calls will simply be function calls - I'd expect plenty of overhead on that end too. Would be interesting to design a realistic benchmark around this. IIRC Michel Weststrate (the author of MobX) had a realistic example based on draggable elements on diagrams, where the diagram link lines needed to be recomputed in realtime as you drag the boxes around. Another realisitc option would be large dashboards made of tables where lots of data updates come in real time.