Rethinking Backbone.js View Rendering

#1

Post by elving » Fri, Mar 08, 2013, 3:08 PM UTC

Rethinking Backbone.js View Rendering
elving.me

Re: Rethinking Backbone.js View Rendering

#2

Post by jscheel » Fri, Mar 08, 2013, 3:26 PM UTC

I absolutely love Backbone, but the biggest issue for me has been dealing with complex logic in the templates. Most of the time now my render() method just builds the darn elements right in there.

Re: Rethinking Backbone.js View Rendering

#3

Post by catshirt » Fri, Mar 08, 2013, 3:26 PM UTC

OP started using Handlebars helpers. there is no "rethinking" happening here and it hardly even pertains to Backbone.

Re: Rethinking Backbone.js View Rendering

#4

Post by condiment » Fri, Mar 08, 2013, 3:28 PM UTC

Correct me if I'm wrong, but wouldn't the best place to combine and transform model data be in the model itself?

For trivial cases, this could be implemented in the model's 'defaults' function. (by computing the transformed field value in the function and returning a hash) If you forsee the need to update the value of the dynamic field in response to the client updating the model, you can perform the calculation again in the Model's 'validate' function.

Speaking from experience, logic in templates is convenient for trivial use cases, but can be very difficult to maintain once a project grows.

Re: Rethinking Backbone.js View Rendering

#5

Post by tomhallett » Fri, Mar 08, 2013, 3:29 PM UTC

At tout.com, we were having timing issues with view rendering, for example if the view has a flash element in it and the $el isn't in the dom yet, you can't operate on the flash element in the render function.

I summarized our new best practice here: http://tommyhallett.tumblr.com/post/37318050812/avoiding-ren...

Re: Rethinking Backbone.js View Rendering

#6

Post by clschnei » Fri, Mar 08, 2013, 3:31 PM UTC

condiment wrote: post #4

Correct me if I'm wrong, but wouldn't the best place to combine and transform model data be in the model itself? For trivial cases, this could be implemented in the model's 'defaults' function. (by computing the transformed field value in the function and returning a hash) If you forsee the need to update the value of the dynamic field in response to the client updating the model, you can perform the calculation agai…

"logic in templates is convenient for trivial use cases, but can be very difficult to maintain once a project grows"

Agreed, my first thought was that there is no way to actively debug the template logic.

Re: Rethinking Backbone.js View Rendering

#7

Post by jashkenas » Fri, Mar 08, 2013, 3:32 PM UTC

Yes, absolutely pass models directly to your views. That's what they're for, after all -- keeping together a handy bunch of methods that can display your data in ways that are terrifically useful for a view to show:

    account.statusWarning()

    document.listOfCollaborators()

    photo.similar.first().publicUrl()

... and so on. But by all means, don't use Handlebars to do it. Use a templating engine that allows real logic, and rest easier at night. Handlebars is set up as faux-logicless templating -- A wolf in Mustache.js' clothing. Having to add Handlebars helpers just to be allowed to call a "method" (as shown in the blog post) is pretty silly example of forced indirection, no? Much more straightforward with embedded JavaScript:

    {{ model.getFullName() }}

Re: Rethinking Backbone.js View Rendering

#8

Post by csallen » Fri, Mar 08, 2013, 3:43 PM UTC

jashkenas wrote: post #7

Yes, absolutely pass models directly to your views. That's what they're for, after all -- keeping together a handy bunch of methods that can display your data in ways that are terrifically useful for a view to show: account.statusWarning() document.listOfCollaborators() photo.similar.first().publicUrl() ... and so on. But by all means, don't use Handlebars to do it. Use a templating engine that allows real logic, and…

I recently started learning EmberJS which forces the user of Handlebars. I thought maybe I was crazy, or maybe I was missing something, but your comment makes me feel a little bit more sane.

Why oh why would you ever use Handlebars over, say, Underscore's templates which allow actually logic? In my (admittedly limited) experience, both choices are equally as simple when writing simple templates, but Handlebars is a colossal pain in the ass when trying to do something significant.

Re: Rethinking Backbone.js View Rendering

#9

Post by [deleted] » Fri, Mar 08, 2013, 3:46 PM UTC

jashkenas wrote: post #7

Yes, absolutely pass models directly to your views. That's what they're for, after all -- keeping together a handy bunch of methods that can display your data in ways that are terrifically useful for a view to show: account.statusWarning() document.listOfCollaborators() photo.similar.first().publicUrl() ... and so on. But by all means, don't use Handlebars to do it. Use a templating engine that allows real logic, and…

[deleted]

Re: Rethinking Backbone.js View Rendering

#10

Post by elving » Fri, Mar 08, 2013, 3:48 PM UTC

jashkenas wrote: post #7

Yes, absolutely pass models directly to your views. That's what they're for, after all -- keeping together a handy bunch of methods that can display your data in ways that are terrifically useful for a view to show: account.statusWarning() document.listOfCollaborators() photo.similar.first().publicUrl() ... and so on. But by all means, don't use Handlebars to do it. Use a templating engine that allows real logic, and…

Makes sense. The idea of using Handlebars instead of embedded Javascript is that the template can't actually change the model, just get data from it, so there's no real logic on the template. Of course this is all theory, as I said in the blog post, it was just an idea. Once I use this approach, I can definitely state the pros and cons.