3 ms·
How do you manage side-effects when working with the DOM?
I started working with JavaScript a few months ago for something I've been working on in my spare time. I find that there are pieces
that I love and pieces that I hate, but the pieces that I love usually enable a level of expressiveness that lets me fix the
broken bits or at the very least work around them in an elegant way.
One piece that I struggle with and have yet to find a good model for working with is the DOM -- the big piece of global state
right in the middle of my application. I've tried a few things to mitigate the inevitable problems. At first I tried wrapping up
elements in objects and treating them as private instance variables. Of course the elements were still global and I quickly grew
tired of this metaphor. My new strategy is to basically treat the DOM as a database. I use a CSS selector to grab elements I care
about and then apply changes by mapping a function over the resulting set. I never store references to the elements and simply
use the selector to get the elements I care about at any given time. I never make any assumptions about the state of the element
and merely 'apply' the changes onto the element.
But of course almost all of my functions are riddled with side effects. My strategy to prevent this from becoming over complicated
has been to keep my code base as small as possible so I can see at a glance what's going on.
So, to all the hackers out there that are much more clever than I am, please help a guy out. What strategies do you use to work with
the DOM? Am I even approaching the problem from the right direction?
- warfangle 18y agoI work with objects that have immediate value - e.g., a form will be an object that has a reference to fields of interest, and member methods that listen to form events to achieve validation, et cetera. I keep DOM elements as instance variables, because it's faster to access them that way than with selector engines. It also neatly separates my behavior - the JavaScript - from my presentation. If another piece of the page's script layer needs to listen to my form object, it can subscribe to the events that it publishes. Basically, I treat DOM elements as the display portion of an object, and if another object needs to change it, it can fire an event. Keeps things nice and loosely coupled. And I typically keep any methods that update the DOM in a separate method - keeps everything nice and organized... It's an interesting topic, and one that probably needs a little more exposition than this.
- sfioritto 18y agoThis seems like a clean approach and one that I've heard before. I now build function generators that wrap functionality around passed in elements and then register these functions with events -- so basically what you are doing except with closures instead of objects. I've found this approach useful where I'd prefer not to use a CSS selector over and over again. My suspicion is that these problems have been solved already by programmers creating traditional event-driven GUI applications. This is unfortunately something I have no experience in so I can only guess that there is some overlap in these problem domains.