67 votes

Pourquoi ref = 'string' est "legacy"?

Dans la Réagir la documentation qu'ils disent:

Réagir prend également en charge à l'aide d'une chaîne de caractères (au lieu d'un rappel) comme une ref prop sur n'importe quel composant, bien que cette approche est la plupart du temps héritage à ce point.

https://facebook.github.io/react/docs/more-about-refs.html

Prenons l'exemple suivant:

class Foo extends Component {
  render() {
    return <input onClick={() => this.action()} ref={input => (this._input = input)} />;
  }
  action() {
    console.log(this._input.value);
  }
}

Pourquoi devrais-je préfère cela, au lieu de:

class Foo extends Component {
  render() {
    return <input onClick={() => this.action()} ref='input' />;
  }
  action() {
    console.log(this.refs.input.value);
  }
}

?

Il semble beaucoup plus propre et plus facile le deuxième exemple.
Existe-il des risques que la méthode de chaîne sera obsolète?


NB: je suis à la recherche de la "officielle" de la réponse à l'instruction de la documentation, je ne suis pas de demander à propos de ses préférences personnelles et ainsi de suite.

50voto

noppa Points 2596

Alors que peut-être plus simple, le vieux refs de l'API peut être difficile dans certains cas limites, comme lorsqu'il est utilisé dans un rappel. Tous les types de l'analyse statique est une douleur avec des cordes, trop. La fonction de rappel en fonction de l'API peuvent tout faire, la chaîne de l'API peut le faire et en plus avec juste un peu de verbosité.

class Repeat extends React.Component {
  render() {
    return <ul> {
      [...Array(+this.props.times)].map((_, i) => {
        return <li key={i}> { this.props.template(i)    } </li>
      })
    } </ul>
  }
}

class Hello extends React.Component {
  constructor() {
    super();
    this.refDict = {};
  }

  render() {
    return <Repeat times="3" template={i => <span ref= {el => this.refDict[i] = el}> Hello {i} </span>} />
           {/*                                    ^^^ Try doing this with the string API          */}
  }
}

Plus de discussion, et un peu plus complet de la liste des problèmes possibles avec la chaîne de caractères en fonction de l'api peuvent être trouvés à partir de la question n ° 1373, où la fonction de rappel en fonction de l'api a été introduit. Je vais l'inclure ici une liste à partir de la description du problème:

La ref de l'API est cassé à plusieurs aspects.

  • Vous devez vous référer à ce.refs['nomutilisateur'] comme les cordes à la Fermeture du Compilateur en Mode Avancé compatible.

  • Il ne permet pas à la notion de multiples propriétaires d'une seule instance.

  • Magique des chaînes dynamiques potentiellement briser des optimisations dans les machines virtuelles.

  • Il doit être toujours cohérent, parce qu'il est résolu de façon synchrone. Cela signifie que les lots de rendu introduit des bugs potentiels.

  • Nous avons actuellement un crochet pour obtenir de la fratrie refs de sorte que vous pouvez avoir une composante reportez-vous à son frère comme un cadre de référence. Cela ne fonctionne que d'un niveau. Cela rompt la capacité à envelopper l'un de ces dans une encapsulation.

  • Il ne peut pas être statiquement typé. Vous avez la lancer à toute utilisation dans des langues comme des caractères d'imprimerie.

  • Il n'y a aucun moyen de joindre la ref de la bonne "propriétaire" dans un rappel invoquée par un enfant. <Child renderer={index => <div ref="test">{index}</div>} /> -- réf sera joint où le rappel est émis, non pas dans l'actuel propriétaire.


Les docs d'appel de l'ancienne chaîne de l'API "legacy" pour la rendre plus claire que le rappel de l'API basée sur l'approche privilégiée est, comme il est discuté dans ce commit et dans ce PR qui sont ceux qui ont mis ces déclarations à la documentation en premier lieu. Notez également que quelques-uns des observations impliquent que la chaîne en fonction de refs api peut être obsolète à un certain point.

18voto

realseanp Points 450

Posté par danabramov sur https://news.ycombinator.com/edit?id=12093234

  1. Chaîne de refs ne sont pas composables. Un emballage composant ne peut pas "sauter" sur une ref à un enfant s'il a déjà une chaîne réf. D'autre part, la fonction de rappel refs n'ont pas une seule propriétaire, de sorte que vous pouvez toujours composer.
  2. Chaîne de refs ne fonctionnent pas avec l'analyse statique comme Flux. Le flux ne peut pas deviner la magie que cadre pour que la chaîne de ref "apparaître" this.refs, ainsi que son type (qui peut être différent). Rappel refs sont plus respectueuses de l'analyse statique.
  3. Le propriétaire d'une chaîne de ref est déterminé par le cours d'exécution du composant. Cela signifie que, avec un bon "rendu de rappel" modèle (par exemple, <DataTable renderRow={this.renderRow} />), le mauvais composant sera propriétaire de la ref (il va finir sur DataTable au lieu de votre composant définissant renderRow).
  4. Chaîne de refs de la force de Réagir pour garder une trace de l'exécution de la composante. Ceci est problématique car il rend l' react module dynamique, et donc les causes d'erreurs bizarres lorsqu' react module est dupliqué dans le bundle.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X