Façon appropriée d'appeler render() dans BackboneJS

Question

Dans la plupart des exemples BackboneJS que j'ai vus, les vues parentes appellent la fonction render() sur les vues enfant. Cela me semble un peu étrange. Peut-être que c'est complètement pour l'optimisation ou autre chose, mais je ne vois pas pourquoi l'optimisation ne pourrait pas avoir lieu dans la vue enfant elle-même. La vue enfant ne devrait-elle pas être responsable de l'appel de sa propre fonction render() ? J'ai l'impression que dans toutes mes vues, je finis par quelque chose du genre :

initialize: function() {
    this.render();
}

De plus, si ma vue parent met à jour les données de la vue enfant model comment l'enfant est-il censé savoir que le modèle a changé (et par conséquent render() doit être appelé) ? Je suppose que dans ce cas, le parent est obligé d'appeler la fonction render() . Bien que cela soit en quelque sorte déduit, pourquoi le parent devrait-il savoir que l'enfant doit effectuer un nouveau rendu lorsque son modèle est modifié ? Il semble que l'appel de la fonction de rendu de la vue enfant soit en dehors du domaine de la vue parent.

Answer 1

Comme pour presque tout ce qui concerne Backbone, il s'agit d'une question assez subjective. Mais voici quelques raisons pour lesquelles vous pourriez vouloir que les parents fassent le rendu :

• Il est parfaitement raisonnable de penser que la vue parent puisse avoir besoin de s'assurer que les vues enfants sont rendues avant que le reste du rendu n'ait lieu. Par exemple, le parent peut avoir besoin de dimensionner un élément conteneur en fonction de la taille de ses enfants, ou de n'afficher un conteneur qu'une fois son contenu rendu par les vues enfant.

• Votre modèle de "rendu lors de l'initialisation" ne fonctionne que si vous n'avez pas besoin de faire d'autres choses avant. change événement, appeler this.model.fetch() et rendre dans le callback. Dans ce cas, surtout si vous vous souciez de l'ordre d'exécution des différents rendus, il est préférable d'avoir un seul écouteur d'événement sur le parent et de laisser le parent s'occuper du rendu des enfants, plutôt que d'avoir des liens avec chaque enfant, même si ces enfants n'appelleront pas fetch() .

• De plus, le fait que le parent rende les enfants ne permet pas exclure les enfants se re-rendant eux-mêmes, par exemple en réponse à des événements plus spécifiques. Le fait que le parent appelle child.render() permet juste de s'assurer que cela s'est produit au moment où le parent a terminé le rendu.

Il est également intéressant de noter que les vues ont une option par défaut pour les éléments suivants render . Ainsi, le parent peut appeler render() sur l'enfant sans avoir à être sûr qu'il fera quelque chose.

Pour répondre à la question "Que se passe-t-il si le parent change le modèle de l'enfant ?", une option consiste à ne pas le faire - toujours créer un nouvel enfant pour chaque nouveau modèle. Mais il se peut que cela ne corresponde pas à votre architecture. Dans ce cas, il est tout à fait logique que le parent soit responsable du nouveau rendu de l'enfant.