2011-12-01 14 views
20

Viniendo de GWT, Backbone parece perder una solución incorporada sobre cómo manejar el ciclo de vida de una vista. En GWT, cada actividad, que es más o menos equivalente a una Vista en Backbone, es administrada por un ActivityManager que llama aStart/onStop en la actividad, pasando el eventBus y el elemento donde se puede representar la actividad. En stop, el ActivityManager desvinculará todos los eventos que la actividad haya vinculado al eventbus y eliminará la vista del DOM.Patrón para administrar vistas en la red troncal

En Backbone, es fácil vincular los eventos al modelo y la colección, pero tiene que eliminarlos manualmente y no hay un método común de API donde lo haga.

Así que estoy buscando un patrón de mejores prácticas sobre cómo administrar las vistas para garantizar que no se escuchen las vistas inactivas o inactivas de los eventos.

Respuesta

13

tiene razón, no hay una versión en solución para eso (todavía).

sin embargo, es por supuesto posible extender la columna vertebral para proporcionar esta funcionalidad, Derick Bailey ha escrito un post sobre esto recientemente,

echar un vistazo aquí: http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

esto no es en absoluto el Santo Grial, eres libre de implementarlo como desees, pero es un enfoque muy directo, para manejar vistas de zombies, ahora todavía necesitas cuidar de otras criaturas que se arrastran en tu memoria, pero esto es un comienzo con las vistas ¡al menos!

+0

Buen artículo. Gracias por el enlace. – ProTom

+0

Sí, el artículo va en la dirección correcta, pero después de todo, la vista es responsable de la limpieza. Estoy buscando una solución donde la vista no se preocupe por la limpieza, porque alguien más lo está haciendo. Piense en equipos más grandes donde a veces alguien se olvida de limpiar manualmente. También debe escribir el mismo código una y otra vez. –

+0

tal sistema no existe con la red troncal, porque quieren proporcionar una estructura que sea y se mantenga flexible, por supuesto, no es improbable que alguien haya pensado en esto, y comenzó un complemento, sin embargo, no he oído hablar de uno que haga todo esto automáticamente (todavía). – Sander

5

estoy usando un Visión de base personalizada, que se extiende método remove del Backbone:

app.BaseView = Backbone.View.extend({ 

    views: [], // array to keep a ref of child-views for proper disposal later on 

    remove: function() { 

     // dispose any sub-views 
     _.each(this.views || [], function(view) { 
      view.remove(); 
     }); 

     // if the inheriting class defines a custom on-remove method, call it! 
     _.isFunction(this.onRemove) && this.onRemove(); 

     // unbind all events from this view 
     this.off(); 

     // finally, call Backbone's default remove method to 
     // remove the view from the DOM 
     Backbone.View.prototype.remove.call(this); 
    } 
} 

Todavía hay un problema: los modelos y colecciones tienen que ser eliminados a mano, ya que no sabemos si es utilizado por otras vistas también

2

Publiqué mi solución para administrar la vista en https://github.com/thomasdao/Backbone-View-Manager.

El administrador de vistas siempre limpiará la vista existente antes de crear una nueva vista. Ahora voy a inicializar una nueva vista por:

newView = VM.createView("newView", function(){ 
      return new View(); 
      }; 

Si quiero volver a utilizar una vista en lugar de crear uno nuevo, puedo usar

newView = VM.reuseView("newView", function() { 
       return new View(); 
      } 

La diferencia entre VM.reuseView y VM.createView es que, reuseView buscará una vista existente con el nombre "newView", si se encuentra, volverá a usted. De lo contrario, ejecutará la función de devolución de llamada y el resultado de la caché. VM.createView siempre ejecutará la función de devolución de llamada y limpiará la vista existente por usted. Por lo tanto, es posible que desee utilizar VM.createView si las vistas son dinámicas y cambian con frecuencia

Cuestiones relacionadas