Forma apropiada de invocar render() en BackboneJS

Question

En la mayoría de ejemplos de BackboneJS que he visto, las vistas principales llaman a la función render() en vistas secundarias. Esto me parece un poco extraño. Tal vez sea completamente para optimización o algo así, pero no veo por qué la optimización no podría tener lugar dentro de la vista hija. ¿No debería la vista infantil ser responsable de llamar a su propio render()? Parece que en todos mis puntos de vista termino con algo como:

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

Además, si mi vista padre actualiza la propiedad de la vista del niño model, cómo es el niño supuesto saber que el modelo ha cambiado (y por lo tanto render() necesidades ser llamado)? Supongo que en este caso el padre se ve obligado a llamar al render() del niño. Aunque se infiere de algún modo, ¿por qué los padres deben saber que el niño debe volver a hacer el diseño cuando se modifique su modelo? Parece que llamar a la función de representación de la vista secundaria está fuera del dominio de la vista principal.

Answer 1

Como casi todo lo relacionado con la columna vertebral, esta es una pregunta bastante subjetiva. Pero aquí hay algunas razones por las que podría querer a los padres que hacen:

• Es perfectamente razonable pensar que la vista padre podría necesitar asegurarse de que los puntos de vista del niño se prestan antes que el resto de la representación se lleva a cabo. Por ejemplo, el padre puede necesitar dimensionar un elemento contenedor según el tamaño de sus elementos secundarios, o mostrar un contenedor solo una vez que sus contenidos sean representados por las vistas secundarias.

• Su "rinden en initialize" modelo sólo funciona si no es necesario hacer otras cosas primero - por ejemplo, un patrón común es que el fin de unirse al evento del modelo change, llamar this.model.fetch(), y rinde en la devolución de llamada. En este caso, especialmente si le importa el orden de ejecución de los diferentes renders, es bueno tener un solo detector de eventos en el padre y luego hacer que el padre trate con el renderizado de los hijos, en lugar de tener enlaces con cada hijo, aunque esos niños ganaron No llame al fetch().

• Además, hacer que el padre represente a los hijos no excluye que los niños se vuelvan a renderizar, p. Ej. en respuesta a eventos más específicos. Hacer que el padre llame al child.render() solo ayuda a asegurar que esto haya sucedido cuando el padre haya terminado de renderizar.

Es también digno de mención que las opiniones tienen un defecto no-op para render. Entonces el padre puede llamar al render() en el niño sin tener que estar seguro de que hará algo.

Respondiendo a "¿y si el padre cambia el modelo del niño?", Una opción es, no lo haga; siempre cree un nuevo niño para cada nuevo modelo. Pero eso podría no ajustarse a su arquitectura, en cuyo caso, tener el padre responsable de volver a representar al niño tiene mucho sentido.