Verschachteln von Views in Views in backbone js

Arbeite ich mit backbone.js Gebäude, die eine komplexe Sicht der Beziehungen, und ich Frage mich, ob es irgendwelche Probleme aus der javascript-performance-Standpunkt aus etwas zu tun, sieht wie folgt aus:

var viewOne = Backbone.View.extend({
         tagName : 'li',
         initialize : function() {
              this.v2 = new viewTwo({parent:this});
         },
         clickHideOne : function() {
              $(this.el).removeClass('selected');
         }
});

var viewTwo = Backbone.View.extend({
         tagName : 'a',
         initialize : function() {
              this.bind('click', this.clickHide, this);
         },
         clickHide(){
              $(this.el).removeClass('selected');
              this.options.parent.clickHideOne();
         }
});

Wo ist dies ein sehr einfaches Beispiel für ein Zirkelbezug zwischen zwei Ansichten, um Ereignisse in einer Ansicht leicht vermehren, bis eine Kette von Ansichten oder erhalten alle Verweise auf Objekte in der übergeordneten Ansichten. Gibt es irgendwelche Situationen, in denen dies zum problem werden könnte, insbesondere in Bezug auf die mögliche Lecks mit DOM-element-Referenzen in IE7+, oder gibt es eine andere bewährte Methode für die Referenzierung von übergeordneten Ansichten.

Außerdem, ich verstehe, dass ich nur tun, $(dies.el).parent('li').removeClass('selected'); in viewTwo, das ist nicht der Punkt... das nur ein sehr einfaches Beispiel für die Frage, ich habe über die zirkuläre Referenz.

InformationsquelleAutor tgriesser | 2011-10-05

15

Dass eine übergeordnete Sicht verantwortlich für untergeordnete Ansichten ist keine schlechte Idee, und ist ein Recht häufiges Szenario, in backbone. Das problem sehe ich mit dem code oben ist die Tatsache, dass die untergeordneten Ansicht hat in Kenntnis der übergeordneten Ansicht. Ich würde empfehlen, benutzerdefinierte Ereignisse in der viewTwo und viewOne binden an diese Ereignisse und dann entsprechend reagieren.

Dies ist ganz einfach mit Rückgrat, die mithilfe der trigger () - Methode und die bind () - Methode.
- Das klingt nach einer guten Methode, ich glaube, ich bin auch Fragen, warum es speziell schädlich sein für das Kind, Blick über Kenntnisse in der übergeordneten Ansicht?
- Weil das Kind-Objekt ist nicht verantwortlich für die Erstellung des übergeordneten Objekts sollte es haben keine Kenntnis von Ihr und komplett unabhängig. Sie sind im Grunde das erstellen von unnötigen Abhängigkeiten.
- Aber wäre es nicht sinnvoll, wenn es eine Abhängigkeit des übergeordneten Objekts... wie wenn das untergeordnete Objekt konnte nicht existieren, ohne das übergeordnete Objekt - und, dass man nur wechseln, auf welches Objekt die "Eltern" der Ansicht, anstatt Sie zu re-definieren, die bindet und löst
InformationsquelleAutor Kyle Rogers
2

Zirkuläre Referenzen sind eine schlechte Idee. Es ist auch keine gute Praxis, als Kyle sagte, dass ein Kind anzeigen müssen eine ausdrückliche Bezugnahme auf die übergeordneten Ansicht. Explizite Verweise gehen sollte die view-Hierarchie nur. Das heißt, es ist in Ordnung, typisch für eine übergeordnete Sicht auf die explizite Verweise auf alle untergeordneten Ansichten und Methoden aufrufen untergeordneten Ansichten mit Ihnen zu interagieren. (Siehe Rückgrat.Untersichten mixin für jede Art zu erstellen und zu verwalten untergeordneten Ansichten). Jedoch, beste Kapselung der Praxis diktiert Blick sollte nie müssen Sie explizite Verweise oder direkt rufen direkt Methoden zu Ihrer Geschwister oder Ihrer Eltern.

Zur Kommunikation mit Geschwistern oder Eltern, haben Sie drei Optionen, die ich mir bewusst bin:
1. Verwenden view.trigger() um ein Ereignis auszulösen, auf das untergeordnete Ansicht (oder Geschwister), und dann haben die Eltern (oder Geschwister) zu hören, die Veranstaltung mit view.listenTo(). Dieser Ansatz funktioniert aber beginnt zu brechen, wenn Sie ein Kind wollen Blick auf die Kommunikation mit seinem Großvater, etc. Auch, Sie erstellen nicht benötigte explizite Abhängigkeiten wenn Sie diese Methode verwenden mit den Geschwistern.
2. Können Sie Rückgrat.Kurier, das ist ein plugin, das macht es leicht zu sprudeln events in der view-Hierarchie. Für die Kommunikation zwischen Geschwister-Ansichten, Geschwister Blasen ein Ereignis bis zu den übergeordneten, und dann der Elternteil ruft eine Methode von der anderen Geschwister direkt.
3. Können Sie eine event aggregator zu handeln, als ein intermediate-Objekt zwischen Kind und Eltern oder zwischen Geschwistern. So können diese Ansichten kommunizieren durch den aggregator, ohne explizite Verweise auf einander. Dieser Ansatz erfordert jedoch global aggregator Objekte, und ermöglicht zudem eine criss-crossing der implizite Abhängigkeiten, die schwer zu verwalten, wie die Anzahl der Aufrufe wächst.
- Diese 3 Optionen sind ideal zum behandeln der Kommunikation zwischen den Ansichten.. aber ich Frage mich nur, in einem Fall, dass ich eine Ansicht 'A', das Kind hat Aussicht und einer von Ihnen ruft eine modal, wenn das modal ist es fertig löst. Der modal bricht die Hierarchie, so sollte ich verwenden Event-Aggregator für meine Ansicht", die Einem " hört es?
InformationsquelleAutor Brave Dave
0

Verschachtelung ist ein guter Weg, der Aufrechterhaltung der hierarchischen sichten, die für das schreiben wartbaren code für komplexe Benutzeroberflächen. Im einfachen Beispiel gibt es kaum performance-Probleme, aber in komplexeren Situationen, die Sie brauchen, um Bedenken Sie, wie tief die Verschachtelung geht.
Zum Beispiel mit Hilfe der komplexen cell-Renderer falsch in einem raster aus tausenden von Zeilen, die machen könnte Ihre Anwendung unbrauchbar. In solchen Fällen clevere Optimierungen können in der Regel gemacht werden, zB. mit Renderern für die nur das sichtbare raster-Zellen.

InformationsquelleAutor lorefnon

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.