4 ms·

The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-children https://reactjs.org/docs/reconciliation.html#recursing-o

The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-children https://reactjs.org/docs/reconciliation.html#recursing-on-ch... And it also goes into why index is a poor key (it's basically the same behavior as with no key). Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render. Practically speaking if you know your items won't change, then omitting the key or using index is fine.

benatkin 5y ago
So SolidJS has this solved elegantly? It lets you choose between object identity and index, and it doesn't have that caveat for object identity because it knows what's going into <For> and not just what's coming out of it. Don't omit the key in React unless you want warnings.
ihateolives 5y ago
I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this: ... 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.
- ryansolid 5y ago
  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.
  - mwcampbell 5y ago
    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?
    - ryansolid 5y ago
      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.
    - deleted 5y ago
      [deleted]

benatkin 5y ago

So SolidJS has this solved elegantly? It lets you choose between object identity and index, and it doesn't have that caveat for object identity because it knows what's going into <For> and not just what's coming out of it. Don't omit the key in React unless you want warnings.

ihateolives 5y ago

I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this: ... 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.

ryansolid 5y ago
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.
- mwcampbell 5y ago
  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?
  - ryansolid 5y ago
    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.
  - deleted 5y ago
    [deleted]