Re:Solid.js feels like what I always wanted React to be
by ryansolid on Tuesday March 01, 2022 @11:37AM
(#30516324)
It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Lit.
Re:Solid.js feels like what I always wanted React to be
by mwcampbell on Tuesday March 01, 2022 @03:10PM
(#30519331)
How does Solid avoid the need for user-provided keys? I thought it also had to diff the underlying array. Does it check object identity?
Re:Solid.js feels like what I always wanted React to be
by ryansolid on Tuesday March 01, 2022 @05:07PM
(#30520719)
It does. Just referential check. Our reactivity is nested and we don't want blow out everything so even though there is read/write segregation and immutable interfaces the internals are mutable. In so sorting looks at referential equality, and nested updates don't even trigger list diffing.
Now this does require special process for intaking immutable or big data snapshots where we can't do reference comparison. So we do have a data diffing capability in our nested reactive stores to propagate only what changes. But for the most part common actions like partial updates highly optimized. As well as simple list operations like sorting.
... you can add a new ID property to your model or hash some parts of the content to generate a key.
It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of for me.