Developing for JavaScript has never been easier than it is today thanks to the plethora of freely available open source third party libraries. I’m sure I’ll be writing about many of these in the months to come, but today I want to introduce something that is crucial in JavaScript land. We’ll call it “KWHYD” (pronounced “Quid”) which stands for “Know What the Heck You’re Doing”. What can I say, I’m into naming things these days.
Knockout
I’m a big fan of KnockoutJS, Steve Sanderson’s now famous MVVM library for JavaScript. It may not be your cup of tea: I’ve talked to some pretty smart folks who don’t like mixing the bindings in with the markup. I’ve also met some pretty smart folks who love it’s power, simplicity, and ease of use. As a longtime XAML-head I’m certainly more aligned with the latter. Knockout made my transition to JavaScript and Single Page Applications (SPAs) not only tolerable but downright enjoyable. Whether you use Knockout or not won’t impact the point I’m making, so read on.
jQuery
Another tool that makes life in JavaScript land far more pleasant is the ubiquitous jQuery. My fellow MVP, ASPInsider, and recent founder of WinSitter, Kevin Griffin, is fond of saying “jQuery makes JavaScript not suck.” My version of Kevin’s statement is that “jQuery makes DOM manipulation not suck.” I’ve also heard it said that “if you aren’t using jQuery, you’re doing it wrong” but I’ll leave you to decide that for yourself.
Library Interaction
This is not an introduction to Knockout or jQuery, the Internet is replete with fine examples and tutorials. For me, these two tools are key components in modern web development, and it would seem Microsoft agrees since they are both installed by default with the new MVC4 templates:
One of the arguments against JavaScript is that you don’t really have to know what you’re doing. JavaScript is very flexible and ostensibly forgiving of simple mistakes. Using third party libraries can “enhance” this “feature”. Using multiple libraries exponentially increases the probability that something will go wrong. The interaction between libraries may be subtle so it is exceedingly important you actually Know What the Heck You’re Doing.
The Symptom
To highlight the issue, I’m going to share with you something that happened to me recently. I was working on an application that uses Twitter Bootstrap (see, there’s yet another library at play) for the UI. The app makes heavy use of Knockout for data binding and jQuery for eventing. Here is some psuedo-code to outline the problem:
HTML:
JavaScript:
The problem is that the click event handlers for the option1 and option2 nav pills never fire. I stared at this for quite awhile, made a lot of incorrect guesses, and tried a lot of solutions, all to no avail. The frustration was exacerbated because at one point they DID work. Turns out a seemingly unrelated change was implemented and the UI was never retested, but I’ll address that shortly. Finally, I *saw* it and all was clear.
The Cause
If you are an experienced Knockout developer, you may have already spotted the culprit. If not don’t worry, I won’t make you wait: the offense here is in using the Knockout ‘if’ binding. On the surface, the if binding acts like the visibility binding, only showing the HTML element (and hence its children) if the matching condition is true. What if actually does is physically add and remove elements from the DOM, which is what caused the problem.
When the page loads, and the bindings are created, the value of Companies() is an empty observableArray, which caused the if binding to interpret as false and remove the DOM elements. Since the elements are no longer part of the DOM, jQuery had no targets to bind the events. In other words, it was functioning exactly as designed.
The Solution
It turns out I had recently moved this particular if binding higher in the DOM heirarchy. It used to be in the div after the nav-pills and moving it back there fixed the bug. Another solution would have been to change the binding from if to visible. I’m sure there are more complex solutions, like dynamically adding the jQuery bindings but that seemed unnecessary and nontrivial.
Conclusion
At the end of the day, it was not Bootstrap, Knockout or jQuery at fault: it was me. The true cause was my choice of if instead of visible because I liked the syntax better and not for any technical reason.
What really makes it worse is that by the time I moved the code that caused the problem to surface I DID know how the if binding functioned. I failed to see the unintended consequence and worse still I failed to test the app after the change. In other words, I failed KWHYD at several times during the process. The good news is I won’t make that mistake with if again…