The update of props is not granular enough. about solid

[titoBouzout]

This is what we call "merged effects", instead of adding 1 effect to each prop, it adds an effect that tracks all the props. It's an optimization for avoiding having to create too many effects. You are supposed to use a memo for prop functions that you wish to not re-run.

[ryansolid]

If you look there is shallow diffing taking place here not to over-update the DOM. But yes we loosened the granularity to improve creation speed. The update speed usually is trivial by comparison. Truly static props are hoisted out of the effect but both data-count and id could update so they are there (they call functions so they could be reactive). The way to think of createMemo is the cost of the execution. If you call a function and it is relatively cheap (most things) then it isn't worth wrapping. If it is wrap. This is pretty independent of how it is used.

Finally Qwik gets there grouping from having a VDOM re-render components on non-granular changes, but having granular changes be our only approach has caused this approach to evolve over the past 6 years. The truth of the matter is that purely granular overhead can be significant. This benchmark shows some of the impact as to get good granular scores it pushes you towards a more granular implementation. Especially note benchmarks around creation/removal: https://krausest.github.io/js-framework-benchmark/current.html

[phy-lei]

This is what we call "merged effects", instead of adding 1 effect to each prop, it adds an effect that tracks all the props. It's an optimization for avoiding having to create too many effects. You are supposed to use a memo for prop functions that you wish to not re-run.

Thank you for your response. The term 'merged effects' seems to imply a difference from Qwik, where each prop is individually maintained. This appears odd to me that static props still require memoization by the user. However, I'll adhere to this rule.

[phy-lei]

If you look there is shallow diffing taking place here not to over-update the DOM. But yes we loosened the granularity to improve creation speed. The update speed usually is trivial by comparison. Truly static props are hoisted out of the effect but both data-count and id could update so they are there (they call functions so they could be reactive). The way to think of createMemo is the cost of the execution. If you call a function and it is relatively cheap (most things) then it isn't worth wrapping. If it is wrap. This is pretty independent of how it is used.

Finally Qwik gets there grouping from having a VDOM re-render components on non-granular changes, but having granular changes be our only approach has caused this approach to evolve over the past 6 years. The truth of the matter is that purely granular overhead can be significant. This benchmark shows some of the impact as to get good granular scores it pushes you towards a more granular implementation. Especially note benchmarks around creation/removal: https://krausest.github.io/js-framework-benchmark/current.html

Thanks!! Creation speed escaped my attention.