Modo appropriato per chiamare render() in BackboneJS

Question

Nella maggior parte degli esempi di BackboneJS che ho visto, le visualizzazioni principali chiamano la funzione render() nelle viste secondarie. Questo mi sembra un po 'strano. Forse è completamente per l'ottimizzazione o qualcosa del genere, ma non vedo perché l'ottimizzazione non possa aver luogo all'interno della visualizzazione figlio stessa. La vista bambino non dovrebbe essere responsabile di chiamare il proprio render()? Sembra che in tutti i miei punti di vista io alla fine con qualcosa di simile:

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

Inoltre, se la mia vista padre aggiorna proprietà model della vista bambino, come è il bambino supposto sapere che il modello è cambiato (e quindi render() esigenze da chiamare)? Presumo che in questo caso il genitore sia costretto a chiamare il numero render() del minore. Sebbene sia in qualche modo dedotto, perché il genitore dovrebbe sapere che il bambino ha bisogno di ri-renderizzare quando il suo modello viene cambiato? Sembra che chiamare la funzione di rendering della vista figlio sia al di fuori del dominio della vista genitore.

Answer 1

Come praticamente tutto ciò che riguarda Backbone, questa è una domanda piuttosto soggettiva. Ma qui ci sono alcuni motivi si potrebbe desiderare i genitori a rendere:

• E 'perfettamente ragionevole pensare che la vista padre potrebbe aver bisogno di fare in modo che il punto di vista del bambino sono resi prima che il resto del rendering avviene. Ad esempio, il genitore potrebbe dover dimensionare un elemento contenitore in base alla dimensione dei suoi figli, o mostrare un contenitore solo una volta che il suo contenuto è reso dalle viste secondarie.

• Il tuo "rendering su inizializzazione" modello funziona solo se non c'è bisogno di fare altre cose in primo luogo - per esempio, uno schema comune è per la vista di legarsi alla manifestazione del modello change, chiamata this.model.fetch(), e rendere in la richiamata. In questo caso, specialmente se ti interessa l'ordine di esecuzione dei diversi rendering, è bello avere un singolo listener di eventi sul genitore e poi avere l'accordo padre con il rendering dei figli, piuttosto che avere legami con ogni bambino, anche se quei bambini hanno vinto chiameremo fetch().

• Inoltre, se il genitore esegue il rendering, i figli non precludono il ai bambini che si riproducono da soli, ad es. in risposta a eventi più specifici. Avere la chiamata genitore child.render() aiuta solo a garantire che ciò sia accaduto quando il genitore ha terminato il rendering.

Vale anche la pena notare che le viste hanno un no-op predefinito per render. Quindi il genitore può chiamare render() sul bambino senza dover essere sicuro che farà qualcosa.

In risposta a "cosa succede se il genitore cambia il modello del bambino?", Un'opzione è, non farlo - crea sempre un nuovo figlio per ogni nuovo modello. Ma questo potrebbe non adattarsi alla tua architettura - nel qual caso avere il genitore responsabile della re-rendering del bambino ha perfettamente senso.