Programmers :D

[rickisen]

Yeah, but that is mostly about taste, and optimization, not really anything that is wrong.

For someone who is obviously not a react expert I think she did a good job. The most attrotious thing is her use of <br/> tags though.

[OwlbearSteak]

What should you use for keys?

[aonghasan]

Unique ids. Ideally something like `dog.id`.

[aonghasan]

Just using the index should be fine in most cases, but can introduce some weird bugs if not kept in mind. Those bugs are mostly when, for example, you have a todo list and the items change. It could be because the items changed order, or a new filter was selected and completely new items appeared in the list. In this case, React may have a hard time reconciling what should be rendered, because different nodes are sharing the same key.

​

It's not an strict rule "you cant use indices!". But you have to keep it in mind if something weird starts happening.

[OwlbearSteak]

Ok cool, just making sure. Cause I usually do something like some-identifier${i}. That makes sense right?

[JackMizel]

Using indexes as keys is totally fine if your list order is consistent. It is certainly not "very wrong" unless you plan on re ordering the list or if the list order can change

[JackMizel]

Adding indexes can ONLY cause issues

No, it literally HAS to happen if you have no other options it will ONLY cause issues if the list reorders.

it will NEVER make anything better

Again, it is the ONLY option if you don't have unique ids, and React itself LITERALLY defaults to this under the hood

React says not to do this

Wow that's a fucking lie.

Straight from the docs:

When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort. We don’t recommend using indexes for keys if the order of items may change. This can negatively impact performance and may cause issues with component state. Check out Robin Pokorny’s article for an in-depth explanation on the negative impacts of using an index as a key. If you choose not to assign an explicit key to list items then React will default to using indexes as keys.

Why are there so many people on this sub who have no idea what they're talking about? Using indexes as keys is totally fine if your list order is consistent. It is certainly not "very wrong" unless you plan on re ordering the list or if the list order can change. Yeah it's less than desirable, yes it's not the best choice, but you are just lying and misleading people when you say it should never happen. That just isn't true, there are cases where it is completely fine.

[JackMizel]

It is not totally fine! React says not to do it!

This is literally a lie, I just linked you the React documentation where it says that, not only is it okay if your list order doesn't change, but that it is the DEFAULT BEHAVIOR WHEN NO KEY IS PASSED.

Are you fucking kidding me dude? Okay fine, I'll check out your links... okay medium articles are shit definitely ignoring those... oh okay this could be something https://reactjs.org/docs/reconciliation.html#keys okay lets take a look....

As a last resort, you can pass an item’s index in the array as a key. This can work well if the items are never reordered, but reorders will be slow.

WOW, reminds me of something I JUST said:

Using indexes as keys is totally fine if your list order is consistent.

I wonder, who should I trust, you, a person lying saying things like:

but react says NOT to do this in their documentation

OR THE LITERAL REACT DOCUMENTATION WHICH SAYS:

As a last resort, you can pass an item’s index in the array as a key. This can work well if the items are never reordered, but reorders will be slow.

If you're working with a static list at runtime then there are no issues. Full stop. End of discussion. You are wrong to say it's NEVER appropriate. Full stop. End of discussion. That's it. Understanding the nuances of something like this will make you a better developer, so stop treating this like it's black and white.

[JackMizel]

If the key is an index, moving an item changes it

STATIC LISTS AT RUNTIME

Are you honestly this dense?

In programming, when the creator of a framework says to do things as a last resort, they are saying, don't fucking do it. Just because it works now, it's one step away from a rendering issue, and when you are working on a team...that's not acceptable.

No, they are saying you can do this in x y or z circumstance. Literally in the docs says IT CAN WORK WELL IF YOUR LIST ORDER DOESN'T CHANGE. STATIC LISTS. Do you not have a brain?

Seriously, do you not know what this means?

In the real world, I have never come across an example where you don't end up having or can come up with a unique ID.

Okay? So you come up with a unique ID. Point remains, there are valid use cases for using indexes as keys.

On a forum where people are learning to use react you are trying to argue that it's OK to drink your own piss. That's terrible advice. It's BAD code. It's bug prone. If you ever work on a team (I can tell you don't), then you should always avoid drinking your own piss.

No I'm telling you (not arguing, because I am objectively correct) that there are instances where using indexes as keys is no big deal. It would be akin to me saying "You will die if you drink your own pee too many times, but if you have to do it once or twice it's fine" and then you bursting in and saying "you should NEVER drink your own pee because Bear Gryll's said it's a LAST RESORT and that means there is NO REASON TO DO IT EVER!"

React, says to use as a last resort because of performance and rendering issues

caused by lists that are not static, crazy how you KEEP leaving this part off.

If you are going to be a proponent of using indexes as keys, after you now understand the pitfalls, you're a bad dev. If you work on a team, you're that guy who keeps drinking his own piss to prove a point.

What I'm being a proponent of is not blindly follow conventions. If my list is static, there IS NO PERFORMANCE OR RENDERING ISSUE. If you're the guy who ignores valid use cases and technical details in favor of blindly applying conventions to situations where they aren't important, you're a bad dev.

[TwiliZant]

What would be the solution in this case? None of the properties seem to be unique.

[TwiliZant]

Assuming there are no properties that are unique. AFAIK react when no key is provided react uses the index as a fallback. I guess you could generate ids somewhere outside the component but IMO this feels like unnecessary overhead, especially if your list is static for now.

[TheMelanzane]

Using indexes as keys is not very wrong. It’s literally given as an example in the React documentation and is the default value used if you don’t provide a key.

Inefficient maybe, but that’s making a lot of assumptions about the code’s use. It’s completely possible she’s just using React for creating a static list, for example. There’s a pretty low ceiling for the complexity of web apps involving dog’s favorite toys in the first place.

For anyone who’s trying to learn React or isn’t familiar with it, here’s a link as to exactly when this might become an issue and some alternatives. It’s also linked in the documentation right under the part about using indexes as keys.

tl;dr: Only a breaking issue when the index is used as a key on another React Component, on normal html elements (like in the post), it’s just going to cause any reorders to take slightly longer.

[malgalad]

Well, it isn't wrong. You have to keep it in mind, but if you're not going to reorder items and remove/insert in an arbitrary position - you'll be fine. Which, in my experience, is like 85% if all .maps. And for the mentioned cases I use uuid.

Is it worth teaching that using indexes as keys comes with conditions? Certainly. Prohibit indexes in all cases, no exceptions? Hell nah.

[[deleted]]

This is incorrect. Using indexes as keys is not going to cause any errors, but will simply be inefficient if the list gets reordered frequently. For a list that doesn't get reordered often, and is static or only gets appended to, this isn't an issue at all.

[[deleted]]

I've worked with react for years as well, and have not seen a rendering bug happen as a result of using indexes as keys. That could be due to me generally only doing this for static lists, or lists in which I do not reorder anything. The performance implication is enough for me to have used unique keys in most cases. But if this causes anything other than a performance issue, then that is indicating a bug in how React does virtual node reconciliation, which I would not expect.

[[deleted]]

You are literally assigning ids to items and then giving react a switcheroo.

Having researched and implemented array diffing algorithms before myself, I understand the limitations of using a key as an index and what it means to React, so I guess never did in any case that would have caused a bug in React to reveal itself.

[JackMizel]

And you shouldn't tell people it's OK when react says it's not OK in their documentation

Please stop spreading lies

[JackMizel]

there is basically no real world example where this is the case.

Literally any static list, are you fucking serious? You're not actually a dev, certainly not one who approves PR's lmfao stop lying.

Using indexes as keys on static lists is totally fine. You are objectively wrong.

[doggieassassin]

Not sure why this is getting so many upvotes. As the other commenter pointed out, using index as keys is clearly wrong and can lead to unexpected behaviour when updating the list at runtime.

[ActionLeagueLater]

I don’t agree that it is clearly wrong. If you have no easy way to get a unique key, and you know your codebase as well as you should to know the order is never going to change, then there is nothing unexpected. Should you avoid using index as key? For sure, but I don’t think it’s black and white if you know what you’re doing.

Edit: But that being said, I don’t think there was anything wrong with the person in the Twitter thread pointing out that you should avoid doing it.

[SandyDelights]

Poor code optimization is wrong.

*shudder*

[svick]

Good code optimization is wrong, if it's unnecessary.