A view’s responsibility — a lesson on JavaScript and the DOM

  • The blog appears to be down. You can also read it at https://github.com/kjbekkelund/writings/blob/master/publishe... (I'm the author)

    Edit: The blog appears to be up again! Hopefully it'll stay up this time ;)

  • Agree with this on multiple levels, though in practice I find a lot of codebases where views directly call events on passed-in model objects. In simple applications I find the extra level of indirection isn't worth it.

    I put together some similar thoughts on client side code organization a while back: http://happybearsoftware.com/client-side-field-notes.html

  • I've always wondered why it wasn't possible to send a message to an object directly in Javascript. Here, you need to emit the message for EventEmitter to relay it back to the receiver. Though I guess there are benefits to this model as well, like a more centralized control of the whole flow of execution, possible message translations and composition.

  • I came to the same conclusion awhile back. Also, if it is in any way possible, a view should be able to write its own HTML (the rails worl has a concept of JSTs, not sure if that has filtered out yet), and a view should never insert itself into the dom

    What you get is loosely coupled, highly testable (and fast tests, since dom stuff is all in memory) ui code.

  • undefined

  • Is the code meant to have entity characters encodings showing through? Love the post though - very thought provoking!