That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.
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.
Don't omit the key in React unless you want warnings.
... 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.
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.
Could it silence the warning? Yes. However, the React devs choose not to. I think it’s the correct default, but likely needs a more educational warning message.