March 29, 2013 - 3 comments

Separating from the DOM, a JavaScript Story


Most web applications have to talk to a third party API that they don’t control and didn’t write.  A good strategy for dealing with that library is to have all your access to the library go through a wrapper object.

When you use a wrapper object, you can define the wrapper object in terms that are semantically relevant to your application. It also becomes easier to test your application, because you can test it as far as the wrapper and then test the wrapper's interaction with the API separately.  It’s also easier to change the library if needed.

Those features are valuable in front-end development, too. However, many front-end applications intertwine with the DOM or with a library like jQuery in a way that can make the code extremely dependent on the specifics of one particular page setup.

In this XI to Eye video tutorial I walk through the process of treating jQuery and the DOM like a third-party library, and creating a wrapper object to manage interaction with the DOM.


March 30, 2013 at 7:25 am

Hi there! It’s always great to see a push towards clearly separated responsibilities in javascript code. Your example is basically a separation between Model and View, isn’t it? The DualSelectDom object being the view.

Noel Rappin
March 30, 2013 at 8:58 am

Yes, you can think of it as a model/view separation. A lot of people would consider the whole thing to be view, but I think it can be worth finer distinctions as the code gets more complex.

March 31, 2013 at 4:12 am

A library like knockout or a framework like angular provide separation between DOM and login, somewhat similar to what you describe, but they also get rid of the need for jquery by providing automatic 2-way data binding for your DOM-agnostic models.

Sample implementation using ko:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.