3 ms·

The compiler is interesting. I was expecting it to analyse dependencies and create automated useMemo calls around everything. I mean write regular, readable Re

by eknkc 2y ago

The compiler is interesting. I was expecting it to analyse dependencies and create automated useMemo calls around everything. I mean write regular, readable React code someone might write manually. It does not do that, instead it creates a cache context. Something like a single useRef object and writes imperative code to check if a dependency has changed, look up the previous instance of a variable from the cache and use it etc. Also caches JSX segments and stuff. This would work much faster I guess and would be easier to extend. I assumed the svelte / solid / vue way of reactivity was the way forward for granular reactive apps. Avoiding unnecessary rerenders etc but the React compiler does a really good job and you get all the fine grained reactivity benefits for free. Without thinking about it in the code. Optimizing compilers are neat.

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 eknkc 2y ago

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.