4 ms·
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 trig
by 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 agoThe 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.