I know its bad to store data in the DOM, but why?
I've heard over and over again that it is bad practice to "use the DOM as a database."
While I mostly agree with that sentiment, this question is more about the less black and white cases. Keeping in mind the latest revisions to jQuery's .data() methods and the HTML5 data-attribute spec, is it really so bad to stick some data in the DOM for the sake of convenience?
For example, I recently implemented a "live" calculation feature on a table full of inputs by doing something like this:
<table>
<tr>
<td><input type="text"></td>
</tr>
<tr>
<td><input type="text"></td>
</tr>
</table>
jQuery:
$('table').bind('calculate',function(){
var total = 0;
$(this).find('tr').each(function(){
total += $(this).data('value');
});
// display total
});
$('table input').bind('change keyup',function(){
$(this).closest('tr').data('value',$(this).val());
$(this).closest('table').trigger('calculate');
});
This is an over-simplified example because I could skip the calls to .data() and go straight to the input values, but let's imagine a slightly more complex scenario where elements other than inputs are affecting the row values.
Is it wrong to use the DOM to store simple data in this kind of situation?
It's fine to store data in DOM objects. And since your question is specific to jQuery's data API, it's important to understand how the data API works. I wrote an answer explaining its inner workings a while back. The data API only keeps a reference to the DOM objects along with the data, and doesn't store anything inside the DOM objects themselves. All data is stored in plain old JavaScript objects.
The issue of whether that is a good or a bad approach is a matter of personal taste. John Resig, the creator of jQuery, gave a talk at Tech4Africa in 2010 where he talks about this exact issue, and proposes to do away with a separate storage area and link everything with the DOM using the data API. You can see the talk on YouTube (thanks to @tine2k for providing the link). If you listen to the entire talk, you'll find some good examples of why this approach makes sense and keeps things simple.
I believe similar arguments can be made for the other end of the spectrum - to have your data in neatly tucked away objects, and classes, and be separate from the view itself. That sort of thinking comes from traditional architectures such as MVC.
I say it's fine to go with either approach - using the DOM to store data, or using a classical approach. Just don't mix the two, cause then you application model is sprinkled everywhere.
There are some fundamental arguments against using the DOM to store data:
The DOM is supposed to be a view of data. The properties of DOM elements should be metadata for the elements themselves, not data from the model.
You should not add random properties to host objects as you have no idea what they might do with them.
You have the same issue as global variables - if it becomes common practice, you will have to adopt a scheme to avoid name collisions.
There is also the argument that the DOM is a pretty ordinary data store and that object structure with indexes will be much more efficient for anything other than trivial data needs.
If you only have small amounts of data and have full control over your pages, then go ahead and put data in data- attributes and properties. But do not store large chunks or complex structures.
Oh, and I don't think there are any performance issues - accessing an element and its properties in the DOM is likely no faster or slower than accessing some part of an object structure, though I'm sure there are faster and slower ways of doing both.
I don't think there is anything wrong with storing data in the DOM, but I think the issue lies with storing a lot of data in the DOM. The browser does have to muddle through the DOM to output the pages we see, and the more data that is in there the more crap it has to sort out.
I'm sure there are also other reasons as well, this is just my deduction.
链接地址: http://www.djcxy.com/p/35354.html