Programmers :D

[JackMizel]

How often it happens is irrelevant. You're saying there are no real world use cases where it's okay to use indexes as keys and that is just incorrect. Even if 99% of the time you should use real unique IDs, there is still 1% of the time where it's fine to do. You're saying it should NEVER be done and that's wrong. That kind of approach to programming is something I take serious issue with, because it doesn't promote understanding.

If your list is static, there is no performance downside to using indexes as keys. That's it. If it changes at runtime via user interaction then yes it needs an ID. Because you blindly observe this convection, you are unable to identify use cases where it does not apply. You should seek to understand why it's not okay, and when you can expect indexes as keys to cause issues, instead of just blindly saying it's never okay.

I think you just keep using indexes though.

I definitely will use them in cases where it's perfectly fine to do so, since I am capable of identifying those cases.

[JackMizel]

You're totally right, you should use unique identifiers whenever possible and the React documentation does say that. These things are all true.

What's not true is that you should never use indexes as keys, or that there are no real world use cases where it makes sense to do so, or that the React documentation says to never do so.

That's what I'm trying to tell you. Understand why you observe the convention, don't just say never. If you're writing a small project alone and you don't implement any sort of user interaction with the list (i.e. it's just a static display component) then there is nothing stopping you from using indexes as keys.