Description
Currently, the expected way to handle an unknown at compile time number of labels is to put them each in their own component. However, when creating tables, this causes a mess of callbacks, as the only way to do it (that I can think of anyway) is to pass a callback into the table header components, have them create their own unique identifier, and then use a useEffect to give the parent those identifiers, have the parent pass those identifiers to the rows, and then have each row generate its opaque own unique identifiers and pass both to the cells. Note that this doesn't work currently because of these two bugs:
#18594
#20127
However, react already has a way to differentiate items in loops: the key prop. To me, it would make sense to provide a function which merges a key prop with a unique identifier. This would allow the parent to generate the unique identifiers and pass them to the children, rather than having callbacks which cause a rerender. It would even make #20127 less relevant because there would be fewer motivating reasons to do so.
mergeOpaqueIdentifierAndKey is very wordy, but describes exactly what's going on. I don't have any particular preference about the name.
Activity
eps1lon commentedon Feb 14, 2021
Prior art reactjs/rfcs#32 (comment).
Naively we could just append the
key
to the generated id. But this would increase the number of bytes sent when doing SSR and also put new constraints on what kind of strings we can pass tokey
SoAsEr commentedon Feb 19, 2021
The other option would be to sort the keys added once we start the toString and then append their index. We wouldn't even have to use string compare at first. We could sort by length (which is faster) and then fall back to string comparison if their lengths are equal.
potential fix for facebook#20822
SoAsEr commentedon Nov 11, 2021
New approach is totally different and doesn't need this complicated scheme: reactwg/react-18#111