Granular item comparison for <For>

[lxsmnsyc]

Allow <For> to receive another property for granular comparison. Currently, <For> only compares by items, so it doesn't work best for immutable data structures or structures that produces a new, deep copy. This applies mostly for things like Firebase where collection produces a new set of data everytime a change happens. This kind of defeats the purpose of <For> being able to move unchanged items. Since referential equality doesn't really work for immutable data structures, it's better if we can compare something that makes it "unique".

With granular item comparison, we can compare a certain aspect of that item rather than the item itself. Consider:

<For each={items} by={(item) => item.id}>

This way, we can "move" the elements if the item still retains the same id, regardless if the item is referentially different.

[ryansolid]

It comes up time to time so I made a demo a couple of years ago.

https://codesandbox.io/s/explicit-keys-4iyen?file=/Key.js

It's always tricky because while there are cases for this like immutable data it's generally always worse than using nested reactivity or stores. I didn't want to influence things negatively but it is a good tool to have and well writing these control flows can be tricky.The biggest thing to understand is it does have to be a different control flow than the others because it's like the combination of the other 2. Or basically the least optimizable as both the item and the index can change so they both have to be signals.

I'm not opposed to providing this primitive but would like to hear thoughts.

[ryansolid]

Yeah ... solid-primitives is another option. It isn't a primitive as much as a control flow component but we can try them out there too.

[thetarnav]

will do 😃

[ryansolid]

That example is missing fallback handling and there is an optimization that can be done to not create index signals if people don't use the index field. I'm less concerned about the latter, but it should support fallback. And like the other map functions we probably should export the function and Component forms. As these patterns have use outside of the JSX.

[thetarnav]

Separate function and fallback are obvious ones, but not creating signals for index if not needed is very interesting. I'm guessing the mapArray does that? Seams tricky at first...

[trusktr]

This new prop for For should be in core imo.

Sometimes the format of an external API is out of our control. If we receive immutable updates from outside APIs, having to install a library, or re-implement For, to work around Solid's limitation doesn't feel right.

Please give us by={}. : 🙏

[elite174]

Agree, sometimes it's quite useful
Would be nice to see it as the part of solid

[thetarnav]

Made a PR to solid-primitives that adds this: solidjs-community/solid-primitives#59
Feedback highly appreciated :)

[thetarnav]

Published: @solid-primitives/keyed

[elite174]

Have you thought about adding this to the core library? Key comparisons are used quite often...

[lxsmnsyc]

That's what I'm thinking, hence I had an urge to make an idea thread like this. However, since the feature was already achievable through a snippet rather than having to access the internals, I think it's fine not to add it, although exposure can be a good factor about this.