Rethinking Backbone.js View Rendering • Hacker News Board

Re: Rethinking Backbone.js View Rendering

#21

Post by account_taken » Fri, Mar 08, 2013, 4:37 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…

Exactly. We have a generic serialize() method in our models to do common toJSON. In item views, where performance is critical, the view itself transforms a subset of the models properties to JSON.

Re: Rethinking Backbone.js View Rendering

#22

Post by account_taken » Fri, Mar 08, 2013, 4:45 PM UTC

tomhallett wrote: post #5

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...

That was our biggest peeve with Backbone views. We fixed it by having a `renderTo` method instead of `render`. Basically, insert the $el into the DOM first, then call render.

Another benefit to this approach is it makes replacing, disposing views, creating stacked views easy ... That is when renderTo tries to insert into a container and determines a view is already in place, it can call dispose or detach on the existing view. Much simpler than Marionette regions or other view management approaches.

Re: Rethinking Backbone.js View Rendering

#23

Post by ronaldj » Fri, Mar 08, 2013, 4:50 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…

You can call a method with Mustache. You don't event need Handlebars to do that.

Re: Rethinking Backbone.js View Rendering

#24

Post by account_taken » Fri, Mar 08, 2013, 4:59 PM UTC

georgedyer wrote: post #19

jscheel wrote: post #15

Earlier quoted context omitted.

It can get pretty messy at times.

try CoffeeKup: https://github.com/mauricemach/coffeekup or Teacup: http://goodeggs.github.com/teacup/

Try https://github.com/mgutz/funcd. It's straight up CoffeeScript functions patterned after Markaby, Erector. Other CoffeeScript templates we tried did funky things with the context and closures didn't work as expected.

And when performance is a concern, you can't beat string interpolation within CoffeeScript heredoc strings.

Re: Rethinking Backbone.js View Rendering

#25

Post by bjhoops1 » Fri, Mar 08, 2013, 5:14 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…

Yes, Handlebars is explicitly designed for logicless templating. If you need real logic in your View (which I might add is often a good time to step back and possibly refactor your solution), you can always fall back on Underscore's templating.

I frequently do this in my apps - I use Handlebars by default, but fall back on _.template() any time my view's absolutely have to have logic in them.

Since Backbone already depends on Underscore, it's harmless in terms of introduced dependencies.

Re: Rethinking Backbone.js View Rendering

#26

Post by tomhallett » Fri, Mar 08, 2013, 6:06 PM UTC

numbsafari wrote: post #14

tomhallett wrote: post #5

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...

I have a lot of canvas drawing going on in my app (charts) and ran into the same issue. As you point out, appending the element to the DOM before everything is fully rendered can cause all sorts of re-drawing to go on. When that's a concern, I proactively set height/width dimensions on the element before adding it. In cases where that's problematic, I just have the render function of the view either update or remove…

Cool approach! I'll keep that in mind.

Re: Rethinking Backbone.js View Rendering

#27

Post by bjhoops1 » Fri, Mar 08, 2013, 6:18 PM UTC

I find it easier to use Handlebars first, then fall back on _.template() when you need logic in your templates. It's easy : http://brettjonesdev.com/on-templating-in-backbone/

Re: Rethinking Backbone.js View Rendering

#28

Post by jscheel » Fri, Mar 08, 2013, 7:01 PM UTC

account_taken wrote: post #24

georgedyer wrote: post #19

Earlier quoted context omitted.

try CoffeeKup: https://github.com/mauricemach/coffeekup or Teacup: http://goodeggs.github.com/teacup/

Try https://github.com/mgutz/funcd . It's straight up CoffeeScript functions patterned after Markaby, Erector. Other CoffeeScript templates we tried did funky things with the context and closures didn't work as expected. And when performance is a concern, you can't beat string interpolation within CoffeeScript heredoc strings.

Yep, that's usually how I start my render() method (using triple-quote strings). Then I wrap it in jquery and do dom manipulation on it.

Re: Rethinking Backbone.js View Rendering

#29

Post by heme » Fri, Mar 08, 2013, 7:32 PM UTC

Isn't this a bad idea outside of formatting a number as currency?

Also, Why not let JavaScript inject your model data directly into plain vanilla HTML templates? In other words, don't use any template tags at all. These 2 projects are really piquing my interest.

http://blog.nodejitsu.com/micro-templates-are-dead

https://github.com/leonidas/transparency/wiki/Frequently-Ask...

Side benefit is that you can still pre/hybrid render from the server in whatever language you like.

Re: Rethinking Backbone.js View Rendering

#30

Post by ktusznio » Fri, Mar 08, 2013, 7:53 PM UTC

I've found it useful to abstract away render and work with before/afterRender hooks instead. I still call render which has a base implementation that calls the template, but instead of passing just the model or the model's JSON, I pass a context object that I can build up to suit my needs. This way every template is dealing with the same thing, and the whole mechanism is extensible.

https://gist.github.com/ktusznio/5119318