Logic vs intuition on list indexes and rerenders in For loops

[martinpengellyphillips]

From Discord chat:

---

So I encountered some behaviour recently that is not intuitive for me (though it is logically correct). I've put it into a little example: https://playground.solidjs.com/?hash=417467847

Essentially I have a list that uses the index() from a For to find a correct item value in a store outside of Solid's state. When an item in the middle of the list is deleted, it appears in the UI as if the last item in the list was deleted instead. This happens because the function calculating content is not re-run. And the function was not re-run because technically the dependency index() did not change (I'm guessing because of how Solid optimises the render and reuse of nodes).

Which is understandable. But at the same time is confusing because naively it feels like Solid should have been passing a changed index() value to the last component in the list rather than passing updated content values to the earlier component.

The fix is simple, just force the re-run by adding a dependency (unused) on props.item or using something like ids instead of indexes.

---

I thought it an interesting case and when raised in Discord there was some agreement that this might be a good example for the 1.0 docs.

I'll probably write a short blog post about this, so would be happy to contribute to docs as well if there is interest?

[ryansolid]

Solid typically does referential checks. And with its internals relying on mutation this works fine. When you replace an item or remove it referential checks will remove and place new item if applicable. Solid is even more optimized than that though. If you change properties on an object in an array the array doesn't update. We know that it is conceptually the same so no need to reconcile. Under normal situations like typical mutation of array or nested object this will always work.

But that's the thing reconcile can only do so much with deep cloned data. If it is structurally cloned like redux it will attempt to keep references. Failing that it will look for a key property. Default is id but it is configurable. And failing all that it will deep merge. Ie. literally transform the old data to the new. In that case only the leaves change. It thinks these are the same object because it is.. so array never recalculates.

It's arguable if merge option isn't and it fails to find key we should always recreate everything though, but I thought fallback to "key by index" was better.

That being said maybe there is something else weird going on. Since I would think this wouldn't be a problem. I will investigate more.

[martinpengellyphillips]

Thanks for clearly explaining the behaviour @ryansolid

And just to confirm that, yes, changing the reconcile call to reconcile(simulate(raw), {key: 'content'}) fixes the issue.

[ryansolid]

I think the issue might be the view is bound to raw rather than the reactive data. So yes index doesn't change so it continues to show old data. If it was bound to reactive data it would also work.