Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Backbone.js View Rendering

elving.me

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Rethinking Backbone.js View Rendering

#11

Post by clintjhill »

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 would have the opinion that you don't mean "real logic" as much as you mean "model data". In other words if you follow the examples you give, I wouldn't see any reason that the model would not have those fields accessible directly or via a standardized "get" as opposed to direct function calls. I would argue that "real logic" in your view/template is a "real bad" idea.

Edited grammar.

Re: Rethinking Backbone.js View Rendering

#12

Post by hippich »

jscheel wrote: post #2

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.

as long as it is just a view and not data manipulation, what is wrong with that? You do not have to have template at all. What if your view is list generator with classes? Why having template at all?

Re: Rethinking Backbone.js View Rendering

#13

Post by jashkenas »

csallen wrote: post #8
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 c…

The "structured" nature of Handlebars is important if you're using Ember, because it's set up specifically to allow it to parse the interpolations in your templates and determine what attributes you're binding, and so on. But if you're not using Ember, a "colossal pain in the ass" sounds about right.

Do yourself a favor and use true logic-less templates (Mustache, in all of its myriad flavors) if you really believe in that sort of thing. Or make life easy on yourself and use a programming language you already know. Embedded Ruby, embedded JavaScript, embedded PHP (the only kind there is) -- all have the virtue of allowing as much or as little code as you need and want, and allow you to do whatever you need to get the job done.

Re: Rethinking Backbone.js View Rendering

#14

Post by numbsafari »

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 the explicit height/width styling. That seems to help avoid the worst cases of redrawing/flicker.

Re: Rethinking Backbone.js View Rendering

#15

Post by jscheel »

hippich wrote: post #12
jscheel wrote: post #2

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.

as long as it is just a view and not data manipulation, what is wrong with that? You do not have to have template at all. What if your view is list generator with classes? Why having template at all?

It can get pretty messy at times.

Re: Rethinking Backbone.js View Rendering

#16

Post by jashkenas »

clintjhill wrote: post #11
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 would have the opinion that you don't mean "real logic" as much as you mean "model data". In other words if you follow the examples you give, I wouldn't see any reason that the model would not have those fields accessible directly or via a standardized "get" as opposed to direct function calls. I would argue that "real logic" in your view/template is a "real bad" idea. Edited grammar.

I'm afraid I do mean "real logic" -- in terms of "real function calls", or "real math", or whatever else you might want to do. Let me imagine a few more examples:

    inflector.addCommas(arrayOfNames)

    document.publicNoteCount + document.privateNoteCount

    format.quote(email.selectedText())
... you always can stuff all of those things into an arbitrary "viewmodel" JSON object somewhere else outside of the template, but it's frequently clearer and more convenient just to do it where it's needed -- instead of enforcing an extra layer of indirection for no real reason -- by passing around models directly.

I guess I feel somewhat strongly about this because having multiple sources for the same truth is what gets people into trouble so often with client-side apps. (Where by a "truth" I mean something like: "What are the names of the collaborators on this document".) Having that data in your model and then again in your viewmodel, and some parts of your app access it over here, and your templates access it over there, is exactly that sort of unnecessary duplication...

Re: Rethinking Backbone.js View Rendering

#17

Post by georgedyer »

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'm a big fan of adding a CoffeeKup template method right in the view. Then just call

    @$el.html coffeekup.render @template, @
in my render function. But I suppose that gives up keeping the html markup separate. For ui components, though, it just makes sense to me to keep the structure bundled with the functionality that way.

Re: Rethinking Backbone.js View Rendering

#18

Post by clintjhill »

jashkenas wrote: post #16
clintjhill wrote: post #11

Earlier quoted context omitted.

I would have the opinion that you don't mean "real logic" as much as you mean "model data". In other words if you follow the examples you give, I wouldn't see any reason that the model would not have those fields accessible directly or via a standardized "get" as opposed to direct function calls. I would argue that "real logic" in your view/template is a "real bad" idea. Edited grammar.

I'm afraid I do mean "real logic" -- in terms of "real function calls", or "real math", or whatever else you might want to do. Let me imagine a few more examples: inflector.addCommas(arrayOfNames) document.publicNoteCount + document.privateNoteCount format.quote(email.selectedText()) ... you always can stuff all of those things into an arbitrary "viewmodel" JSON object somewhere else outside of the template, but it's…

We agree on having a single source of truth. I'm arguing for it to be derived in a controller and not in a view.

Re: Rethinking Backbone.js View Rendering

#19

Post by georgedyer »

jscheel wrote: post #15
hippich wrote: post #12

Earlier quoted context omitted.

as long as it is just a view and not data manipulation, what is wrong with that? You do not have to have template at all. What if your view is list generator with classes? Why having template at all?

It can get pretty messy at times.

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

Re: Rethinking Backbone.js View Rendering

#20

Post by jscheel »

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/

I used coffeekup back in the day, but I just can't stand the jade-style declarative html. I also used eco for a while, but it got pretty messy too. I'm picky, I know :)
Post reply on HN