2013-10-15 2 views
0

Я использую то же самое el для более чем 1 вида, как показано ниже. До сих пор я не сталкиваюсь с какой-либо проблемой. Является ли этот хороший подход или я должен делать какие-либо изменения?BackboneJS - тот же эль для многих просмотров

<div id="app"> 
    <div id="app-header"></div> 
    <div id="app-container"></div> 
    <div id="app-footer"> 
</div> 

App Вид:

{ 
el: "#app", 

v1: new View1(), 
v2: new View2(), 
render: function() {  
    if (cond1) {  
     this.v1.render(); 
    } else if (cond2) {  
     this.v2.render(); 
    }} 
} 

Вид 1:

{ 
    el: "#app-container", 

    render: function(){ 
    this.$el.html(template); 
    } 
} 

вид 2:

{ 
    el: "#app-container", 

    render: function(){ 
    this.$el.html(template); 
    } 
} 
+0

Все ваши события DOM, определенные в ваших представлениях, будут привязаны к этому элементу, если вы в порядке с этим, то, вероятно, это нормально. Другое дело, что HTML-код всех других представлений исчезнет, ​​если вы когда-нибудь назовете 'remove' или' this. $ El.html (...) 'в одном из представлений. – j03w

+2

Это не хороший подход, я бы сказал, добавьте 4 (столько, сколько вы хотите) дочернего div внутри и которые используют один для каждого представления. как сказал @ j03w, это приведет к проблеме в будущем –

+0

хороших точек. И я не добавляю свой дом прямо в эль. Я добавляю дом в другие div, во всех взглядах. Поэтому я не использую 'this. $ El.html (...)' – user10

ответ

0

Считывая ваш вопрос, я не вижу, какие выгоды Вы могли бы иметь, используя этот подход, а не имеющий разные div элементов являются корнем el для просмотра 1, 2, 3 и использование

this.$el.html(template) 

в методе render.

Ваш подход может работать для небольшого приложения, но я думаю, что будет очень сложно поддерживать, когда приложение растет.

EDIT

я до сих пор на самом деле не получить свою точку зрения, можно только инициализировать все только один раз в обоих случаях.

Адрес working Fiddle. Кстати, я меняю контент, слушая событие click, но это упрощает пример. Это должно быть сделано маршрутизатором.

+0

снова обновил мой вопрос. Мне нужно многократно вызывать 'View 1' render. По моему методу я могу избежать большей инициализации, потому что я инициализировал v2, 3, 4 как свойство v1. – user10

+0

Я отредактировал свой ответ. –

+0

Мое положение точно похоже на это. http://jsfiddle.net/TFtLL/1/. что не так, когда '# container' как' el' в v1, v2 и v3. Как он может стать неуправляемым в больших приложениях. – user10

0

Я использую mixin для обработки такой ситуации, я называю это заявленным видом. Для представления со всеми другими параметрами я вышлю параметр под названием «состояние», рендер будет в свою очередь вызывать renderState в первый раз, и после каждого раза, когда я устанавливаю «состояние», renderState обновит состояние представления. Вот мой код mixin.

var setupStateEvents = function (context) { 

    var stateConfigs = context.getOption('states'); 
    if (!stateConfigs) { 
     return; 
    } 

    var state; 
    var statedView; 


    var cleanUpState = function() { 
     if (statedView) { 
      statedView.remove(); 
     } 
    }; 

    var renderState = function (StateView) { 
     statedView = util.createView({ 
      View: StateView, 
      model: context.model, 
      parentEl: context.$('.state-view'), 
      parentView:context 
     }); 
    }; 

    context.setState = function (toState) { 
     if (typeof toState === 'string') { 
      if (state === toState) { 
       return; 
      } 
      state = toState; 
      var StateView = stateConfigs[toState]; 
      if (StateView) { 
       cleanUpState(); 
       renderState(StateView); 
      } else { 
       throw new Error('Invalid State'); 
      } 

     } else { 
      throw new Error('state should be a string'); 
     } 
    }; 

    context.getState = function() { 
     return state; 
    }; 

    context.removeReferences(function(){ 
     stateConfigs = null; 
     state=null; 
     statedView=null; 
     context=null; 
    }) 

}; 

полный код можно увидеть здесь

https://github.com/ravihamsa/baseapp/blob/master/js/base/view.js

надеюсь, что это помогает

0

Backbone Правило:

При создании экземпляра зрения, ll привязать все события к el, если было назначено, иначе view создает и присваивает пустой div как el для этого представления и связывает все события с этим видом.

В моем случае, если я назначить #app-container для просмотра 1 и вид 2 как el и когда я инициализировать оба представления, как показано ниже в App View все события связываются с одной и той же емкости (я.е # приложение-контейнер)

this.v1 = new App.View1(); 
this.v2 = new App.View2(); 

приведет ли это к каким-либо утечек памяти/Zombies?

Ни в коем случае. Ни за что. Потому что в конечном итоге у вас есть только один экземпляр для каждого представления. Таким образом, это не приведет к утечке памяти.

В чем проблема?

Когда ваше приложение растет, очень часто используется тот же идентификатор для тега в обоих представлениях. Например, у вас может быть button с идентификатором btn-save в обоих шаблонах. Поэтому, когда вы связываете btn-save в обоих представлениях, и когда вы нажимаете кнопку в любом представлении, он будет запускать метод сохранения обоих представлений.

См. Это jsFiddle. Это объяснит этот случай.

Могу ли я использовать такой же el для обоих видов?

Это зависит от вас. Если вы избегаете связывания событий на основе одного и того же имени или имени класса в обоих представлениях, у вас не будет проблем. Но вы можете избежать использования одного и того же идентификатора, но настолько сложно избежать того же имени класса в обоих представлениях.

Так что для меня это выглядит @ Daniel Perez ответ более перспективным. Поэтому я собираюсь использовать его подход.

Смежные вопросы