Yep, I was wondering why "render" would need to be called multiple times.
I usually start off by doing that because I'm lazy, then something usually bites me in the ass (usually - oh hey, we need a transition effect).
And the end result is a bunch of "sub rendering" methods that get called in render ... and as callbacks from model change events. (It's awfully nice when you have to load everything off the server - no default state in the DOM.)
I completely agree with the small render helpers, we've been using that too and it works amazingly. I'll probably write about that next. But I still want `render` to be able to be called multiple times without breaking because it's a public method.
I'd love to read an article about how you guys handle transitions though. We've implemented a few of them, but I have yet to work on them enough to have found really nice patterns.
I usually start off by doing that because I'm lazy, then something usually bites me in the ass (usually - oh hey, we need a transition effect).
And the end result is a bunch of "sub rendering" methods that get called in render ... and as callbacks from model change events. (It's awfully nice when you have to load everything off the server - no default state in the DOM.)