javascript - Backbone views which don't know about their container, models to be fetched via AJAX, no UI/UX trade-offs and maintainable code -

since i'm not totally sure on level issue solved best, i'd summarise path went , things tried first:

it's more or less $el (i think).

as basic backbone examples state, started having $el defined within view, like

invoice.invoiceview = backbone.view.extend({   el: $('#container'),   template: ..,   .. }); 

it didn't feel right, view supposed know parent (=container). paragraph 'decouple views other dom elements' written on http://coenraets.org/blog/2012/01/backbone-js-lessons-learned-and-improved-sample-app/) puts words.

following article's advice, switched passing $el on view while calling render()-method. example:

$('#container').html( new winelistview({model: app.winelist}).render().el ); 

so far - render() gets called, while maybe shouldn't (yet).

for example view asynchronously fetches model in initialize()-routine. adding binding reset or sync (e.g. this.model.bind('sync', this.render, this)) makes sure, render() gets called once model fetched, above stated way, render() still might called while model isn't fetched yet.

not nice, working(tm), solved checking model's existence of primary key:

render: function() {   if(this.model.get('id')) {     ... } 

however, didn't expect - , if isn't documented (at least didn't find it) think should - fetch operation doesn't seem atomic. while primary key ('id') might part of model, rest might not, yet. there's no guarantee model fetched way. whole checking seemed wrong anyway, did research , got pointed deferred.done-callback sounded looking for, code morphed this:

render: render() {   var self = this;   this.model.deferred.done(function() {     self.model.get('..')   };   return this; } .. $('#container').html( new winelistview({model: app.winelist}).render().el); 

it works! nice, hu? ehrm.. not really. might nice runtime-flow's point of view, code quite cumbersome (to put mildly..). i'd bite bullet, if there wouldn't little, tiny detail, code sets (=replaces) view instantly, populates later (due deferred).

imagine have 2 (full-page) views, show , edit 1 - , you'd instantly switch between 2 (e.g. after hitting save in edit-view morphs show-view. using above code sets (=resets) view , then renders content, once deferred fires (as in, once fetching model completed). short flickering or long blank transition page. either way, not cool.

so, guess question is: how implement views, don't know container, involve models need fetched, views should rendered on demand (but once model fetched completely), having no need accept ui/ux trade-offs , - cherry on cake - having maintainable code in end.

first of all, first method found terrible (hard coding selector in view's constructor)

the second: new winelistview({model: app.winelist}).render().el common , ok. requires return reference view render method, , seems follow this, unnecessary.

the best method (imo) attach views element container, this

$('#container').html(new winelistview({model: app.winelist}).el); 

the winelistview doesn't need know it's going used, , whatever initializing winelistview doesn't need worry when render winelistview view instance:

because el live reference html element, view instance can modify anytime wants to, , changes reflect wherever attached in dom/ when gets attached in dom.

for example,

winelistview = backbone.view.extend({   initialize: function(){      this.render(); // maybe call here      this.model.fetch({        success: _.bind(this,function(){          this.render(); // or maybe here         })      });   } }); 

---

regarding flickering: hardly has rendering or backbone, it's you're replacing 1 element , there emptiness tiny bit of time if new view renders instantly. should handle using general techniques transitions, loaders etc, or avoid having switch elements (for example convert labels inputs in same view, without switching view)