That's actually right

_solidjs enters the chat_

You can't decalre a class inside JSX though. You can also use this seemingly reserved keyword between JSX tags, like class. React team can update their JSX parser to allow using the "class" and "for" attributes, but I guess it isn't really a pressing matter.

@@szyszak when you write class you're telling put the string "class" inside a tag. when you want to escape into javascript world you need to use the brackets { } so try writing { class } now you'll get an error since class is a reserved keyword in javascript and React is just Javascript end of the day.

​@@nivethan_me when you write className in JSX, you're doing it inside , which also should tell the parser you're not using the class keyword. It's an arbitrary change

it is clear for you because you were already working for six years on React

My pleasure. Any more topics you'd like me to cover?

@@TheCodeBootcamp Can you do react advanced topics only. Like , proper advanced stuff that is often used too. Or maybe , as a second idea , a list of commonly used libraries and the like.

Thanks for this. Just added chapters.

@code.bootcamp make Vue concepts Plz ser thenks

Why?

@@heyyounotyouyou3761the key is meant to tell react reconciliation when an item in a list changes so it doesn’t need to do rerenders on items which haven’t changed. If your list changes order then the index is not reliable as a key.

@@heyyounotyouyou3761 React uses the "key" prop under the hood to know which elements were kept the same and which ones were added/removed in the next render when a mutation of the list happens. The problem with using index as the "key" is as follows: imagine we have a list containing the strings ["a", "b", "c," "d"], iterating over the list and giving them the index as the "key" prop would generate the following - lets say we remove the string "b" from the list, the map function would generate , as you can see, the elements with the text "c" and "d" now have different keys, so, instead of react knowing the element with the string "b" was deleted, it thinks the element with the string "b" was changed to have "c", the element with string "c" was changed to have "d" and that the "d" element was deleted. This makes react re-render 3 components unecessarily instead of just 1. This might not be a big deal for short lists, but for big ones, it's a huge performance loss. Hope this helps. And if you still don't understand, feel free to ask questions 😄

@@heyyounotyouyou3761 when you render a list of items that can be modified (for example by removing elements) the index will shift and you may see some inconsistencies on the page. If the key is based on a property of the item, then the behaviour is always consistent

What can we use instead

@@omagadavid9923 for all practical cases, for example users, products, posts etc. there should be some unique identifier already present, so you should always use that.

I use crypto.randomuuid

Then what is alternative for index as key

You should never iterate over an iterable that will be modified. You must create a copy of the iterable for the loop and modify the original iterable separately.

Yes, typo

The best font known to man, Comic Sans.

Yes, typo