It would be great to have such a Key component within solid. :)

A suggestion: the prop by may be more flex as a function which returns the key.

I'm not sure followed what I said. It's a de-optimization. It's almost always better to use one of the other methods I mentioned. I'm yet to come across a use case where it is beneficial to use this over another method. Until that happens it's unlikely that this will be added core. But as always go for it, anyone can write/use their own control flow as they are just components.

we can set key in list to optimize dom rendering

Keys are used to maintain order when list items are modified. So their function is more about rendering integrity than optimisation.

I was facing a problem myself with For and deeply nested mutated data (where Solid would see each iteration as new data). My solution was to create unique keys that would not mutate, iterate over the keys and look up the corresponding item.

I've illustrated that approach in a simplified version of the CodeSandbox above

I feel I haven't been clear in explaining what I consider the preferred solution. And to be clear that solution keeps integrity. Obviously recreating all the DOM nodes is not a good option which can happen when you replace objects in a list with <For>. Sure we don't risk other side effects of doing non-keyed (or keyed by index) but it's terribly unoptimal. But maybe I can explain better with a concrete example.

Pretend we have an array of user objects that have some properties on them like id, firstName, lastName, avatarImage, jobTitle, and address. And assume we want to keep integrity between data and DOM nodes. Now if we make the list a Signal and just throw all the data in it and use <For> it will render fine at first. Now when you update the firstName on one row. You will clone the array and the user and set it with the new name. Unfortunately, because <For> only uses referential equality this will re-render that whole row of our results, recreating all the DOM nodes.. very wasteful.

If we had a <Keyed> loop what would happen. Well we'd key by id. So when you clone and update firstName, the following happens:

1. We trigger the list signal and notify the <Keyed> component
2. It runs through and diffs every data element by key doing a lookup
3. It updates a Signal created by <Keyed> for the changed row
4. This notifies every sub binding which re-evaluates each binding on that row tied to the row data, this includes things that are bound to all the fields firstName, lastName, avatarImage and jobTitle.
5. After checking each value it realizes only firstName changed and applies the suitable change.
6. The nodes are returned and shallow diffed against the DOM (this could be skipped with the right implementation on cases like this that don't create or move DOM nodes)

If we had used a Store or nested Signals for or data with <For> this would have happened instead.

1. We trigger the signal for firstName on the particular user
2. It notifies the one place we show firstName and applies the change.

This is the only reason I focus on performance here. The second case is still "keyed" it just does way less work. For that reason I've never desired a Keyed loop. This is the power of fine grained reactivity. Nested updates don't trigger list reconciliation and work completely independently.

The stores section of the Tutorials on solidjs.com goes over this in detail with examples.

I just wanted to add two links to the tutorials that I find useful in understanding this topic:

• Start from this one https://www.solidjs.com/tutorial/stores_nested_reactivity
• and go to until you reach this one https://www.solidjs.com/tutorial/stores_immutable
  The last one explains reconcile utility as Ryan mentioned. This utility provides the smart updates to arrays in your stores which results in granular updates in a list of DOM elements that was created by <For> component.

In my case it was enough to replace this:

setStore({
  tabs: model.tabs
  settings: model.settings,
  zoomFactor: model.zoomFactor,
})

To this

setStore({
  settings: model.settings,
  zoomFactor: model.zoomFactor,
})
setStore('tabs', reconcile(model.tabs))

To make the list of tabs to be granularly updated in DOM.