.js file and randomly jam a bunch of functions in it, and hope someone (a team member, perhaps) didn’t notice them closely enough to attempt to use one in a way in which it wasn’t intended to be used. Knowhatimean? Ever been there, or done that? Perhaps you’re there now.
At some point…not sure exactly when…I guess it was probably about six or eight months ago or so…I finally got to a point where I said to myself, “self…there has GOT to be a better way.” So I did some Googling…and as it turns out, I was right…
The module pattern
Some of the big things that I found myself longing for as the JS I was writing started to get more and more complex, was encapsulation, reuse and statefulness. The searching I did (check out the link above) quickly showed that the module pattern would give me all of that and more. I highly recommend starting with the first link in those results, its a fantastic article by ben cherry that covers how to implement the module pattern with JS in very simple and understandable terms (seriously, if this subject interests you at all, go read it…this page isn’t going anywhere…you may not even want to come back after reading it…).
I started slowly with this pattern to support a few web applications that required some semi-complex client-side interactions, and have been very pleased with how it has worked out so far. Here’s a stripped down sample of the format that the modules I’ve been writing have taken:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Pulling it into a web page
I’ve found this approach to support interactive client-side functionality in web applications very nicely as well, though, this is an area where I admittedly have some questions as to my approach. I’ve been wondering if I sense a slight code smell with the following approach, and would appreciate some feedback. But anyway, here’s how I’ve been using it.
Being the .NET developer that I am, the following is an example of a razor view from an ASP.NET MVC app, that uses the above module, but this same approach could be used with any web frameworks view engine.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
See what I did there? So, the idea here is that the JS module itself knows absolutely nothing at all about the page that it is supporting. But, it can still fully support and manipulate DOM elements on the page, because the page feeds it the selectors it is (obviously) fully aware of by passing the
pageModuleParams object into the module through the publicly exposed
Init operation, which sets the internal
selectors variable. From that point on, the module itself, internally, can wire up internal operations (event handlers, ajax calls, etc) that can act on elements of the page through selectors that were passed in from the page, and yet still remain totally decoupled from the page.
So what do you think? This approach has been working fairly well for me for a while now, but it wouldn’t surprise me a bit to know that there are much better ways to handle this. Any suggestions or recommendations? Learning new and better ways of doing things (especially if they make my life easier) is something I love…so I’m totally open to feedback here. Was this useful?