reactjs / reactjs/react.dev

Highlight Possible Necessity of keys for Conditional Rendering

Aperta
#1,779 0 commenti 5 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Lingua principale
JavaScript
Stelle
11.8k
Fork
7.9k
Merge medio
1g 11h
PR unite (30g)
11

Descrizione

Motivation

Keys may be necessary outside the context of any "list" or array, especially when using conditional rendering. This isn't emphasized enough in the docs, and examples (therein and elsewhere) tend to lead to a false association between keys as having directly to do with map(), <li> elements, or JavaScript arrays. As I understand it, at its root, keys have to do with children, and type correspondence based on position during reconciliation.

Related issues such as https://github.com/reactjs/reactjs.org/issues/79 don't seem to directly address this.

Personal Experience

Most recommendations I find online seem to boil down to "use keys when using map()"(or <li> or arrays). It's rare to find a discussion related to conditional rendering and most people tend to be unaware of it.

I've been in a project wherein conditional rendering was heavily used, which led to a hard to find bug due to the absence of keys.

Code snippet in render()

return (
            <div>
               { this.state.showCounter2 ? 
               (
                <React.Fragment>  
                    <CounterWithLifeCycleLog name={'myCounter1'} 
                    counter={0} />
                    <CounterWithLifeCycleLog name={'myCounter2'} 
                    counter={this.state.counter2} />
                    <CounterWithLifeCycleLog name={'myCounter3'} 
                    counter={0} />
                </React.Fragment>

               ) : (
                <React.Fragment>
                    <CounterWithLifeCycleLog name={'myCounter1'} 
                    counter={0} />  
                    <CounterWithLifeCycleLog name={'myCounter3'} 
                    counter={0} />    
                </React.Fragment>

               )

The above code has a bug. When this.state.showCounter2 moves from true to false myCounter3 will be unmounted instead of myCounter2. Then the new myCounter3 will reuse the backing instance of myCounter2, maintaining its internal state.

It is true that this could be avoided by using the following instead:

&& <CounterWithLifeCycleLog name={'myCounter2'} 
                    counter={this.state.counter2} />

The former example, however, is valid conditional rendering as well.

Proposed solution

An explicit mention of this confusion, an example involving conditional rendering (not using <li>, map(), or arrays), and perhaps a link to this blog post and perhaps the How to force remounting on React components related stackoverflow question.

Also, currently, all warnings related to keys seem to either have to do with arrays or iterators, perhaps a light warning when using conditional rendering could be helpful (though I can see how this will add way too much clutter), or some way to incorporate it into existing warnings.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia individuando le sezioni della documentazione di React che spiegano le keys, le liste e la reconciliation. Usa l’esempio fornito di rendering condizionale per mettere in evidenza la differenza rispetto a map(), agli elementi delle liste e agli array. Il lavoro è completato quando la documentazione spiega chiaramente quando le keys sono importanti nel rendering condizionale e include un esempio dedicato; eventuali modifiche agli avvisi sono considerate facoltative.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
javascript, react
Ambito
documentation
Tipo di issue
Documentazione
Difficoltà
3/5
Tempo stimato
1-2 giorni
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
45/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.