I've recently looked at some front end js code.
(1) In some cases the code creates a new JavaScript object from a JSON received from the back end. Then the newly created object is stored in a cache (say a map). This way the object would be cached on the front end for later use.
(2) I've also seen instances when the new JavaScript object (called eventObject here) is stored in the DOM like this: $(this).data('eventObject', eventObject);
Does it matter which way you store the data? I would personally cache eventObject in a JavaScript cache object (ie make your own cache class or a map). Isn't it simpler to cache like this than mess with the DOM and then you have to remember where you put what?
In my searches I've looked at XML DOM vs Object in Javascript
Isn't it simpler to cache like this than mess with the DOM and then you have to remember where you put what?
jQuery's data method actually doesn't mess with the DOM, it is just a convenient way to reference data objects by DOM nodes.
Of course, if you "have to remember whery you put it" the DOM references are not the best way to reference your objects. If a simple cache object seems cleaner to you, it probably will be cleaner.
Related
To store values in a DOM element, we can do it through data attribute
$("#abc").data("item", 1), to retrieve do $("#abc").data("item")
But today I learned that we can do it this way also:
$("#abc")[0].item = 1, to retrive do $("#abc)[0].item
What are the differences between them?
Which one is better? Which one gets a wider compatibility?
.data() exists for a couple reasons:
Some (mostly older) browsers had memory leak issues if you put a JS object into a property on a DOM object. This created a reference between the DOM and JS world (which have separate garbage collectors) which caused problems and could result in memory leaks. Keep references entirely in the JS world by using .data() instead of a DOM property solved that issue. I don't honestly know how much of an issue this still is in modern browsers. Hard to test, easier to just use the known-safe approach.
Historically, some host objects did not support arbitrary property addition with direct property syntax such as obj.prop = 1;. .data() made it so you could associate data with any object regardless of whether it had the ability to handle any arbitrary property.
Name collisions. .data() creates one and only one custom property on a DOM object which is just an id value (a string). You are then free to use any keys you want with .data() with zero worry about conflicting with a pre-existing property name on a DOM object. .data() is essentially it's own name space for custom properties.
Reading HTML5 "data-xxx" attributes. When you read a .data("xxx") property that has not yet been written to the actual jQuery data store, jQuery will read a "data-xxx" attribute on the DOM object. If it finds that attribute, it returns that value and actually coerces its type too so that "false" gets turned into the Javascript false. If you then write .data("xxx", "foo"), the value is not overwritten onto the DOM object, but is written to the jQuery storage and from then on all future reads writes are from the jQuery .data() store. One reason this is useful is that custom attributes (which are different than custom properties) can only be strings, but .data("xxx", yyy) can write and store any JS data type.
So, if you want to use a known-safe method that is not prone to memory leaks, even in older browsers, use .data() rather than making your own custom property on a DOM object.
I suspect it's possible that at some future time, browsers will be considered safe enough that you can store JS object references in custom DOM properties and not have to worry about memory leaks at which time there may be less reasons to use something like .data() - though issue #3 above will still exist.
There are some disadvantages to using .data().
If you store meaningful amounts of data in .data() and then you remove the corresponding DOM object without using jQuery's methods to remove it (such as you use .removeChild() directly or you just set .innerHTML on a parent), the data stored in the .data() store will be orphaned and never cleaned up because jQuery will not know the corresponding DOM object has been removed. This will result in some data in your javascript being kept in the data structure that you won't ever be using. While this isn't technically a leak (as the data is still there for use), it has much the same effect of wasting some memory. If you use .data(), you should only use jQuery methods for removing or replacing DOM objects because they prevent the wasted memory.
Because of the above issue, when you are using jQuery's methods that can result in the removal of DOM objects, jQuery has to do extra work to make sure .data() is cleaned up when using its own methods. This can slow down the performance of .html("xxx"), .remove(), etc...
I am trying to improve my knowledge of javascript and while searching for some "best practices", someone pointed out to me that it is faster to cache the DOM document and then access it through that var instead of accessing the document object directly.
You can see the results here, on an edit I made on jsperf: http://jsperf.com/jquery-document-cached-vs-uncached/3 (edit: the title holds "jsquery" because that was the original test, my edit contains vanilla javascript, the framework makes no difference)
This really makes me curious. Basically I am introducing a new variable into the equation, how can that make things faster instead of slower?
As far as I know, "print a" should be better than "b = a; print b" (figure of speach)
What's different in this case?
document is not like an ordinary Javascript variable. There's no telling what odd magic is happening under the covers when accessing its attributes, especially the DOM, which may be created on demand from internal browser structures.
I believe I found an explanation here (the emphasis on the last part is mine):
Store pointer references to in-browser objects. Use this technique to
reduce DOM traversal trips by storing references to browser objects
during instantiation for later usage. For example, if you are not
expecting your DOM to change you should store a reference to DOM or
jQuery objects you are going to use when your page is created; if you
are building a DOM structure such as a dialog window, make sure you
store a few handy reference to DOM objects inside it during
instantiation, so you dont need to find the same DOM object over an
over again when a user clicks on something or drags the dialog
window.If you haven’t stored a reference to a DOM object, and you need
to iterate inside a function, you can create a local variable
containing a reference to that DOM object, this will considerably
speed up the iteration as the local variable is stored in the most
accessible part of the stack.
So, if I understand correctly, caching the DOM in a local variable makes it easier to access in the memory stack, therefore increasing the speed of execution.
All too often I find myself storing object data in hidden dom elements. I was curious if there was a way to attach this data to the dom node itself. When I try to create attributes 'on the fly', it doesn't seem to work. It would be much easier to access the property with this.something instead of accessing the html contained in a child. I feel like I should know how to do this, but I don't. Thanks.
There absolutely is! jQuery's .data().
$('#someId').data('myData', someValue); // To store the data
$('#someId').data('myData'); // To retrieve it again
Any JavaScript variable can be stored as data - it's not limited to strings.
Note that this doesn't actually attach data to the DOM node as you say (which should be avoided). jQuery keeps its own cache of all the data you store and the DOM nodes you wanted to attach it to. So, it's not the same as domNode.myData = someValue.
jQuery.data is the preferred way of doing this.
My current style of programming is OO javascript using the Class.extend function by John Resig: http://ejohn.org/blog/simple-javascript-inheritance/
This has been fine but I find myself writing numerous setters and getters that only get used on init. Also, it seems to lead to memory leaks in IE when storing instances of these objects in an array for later use.
I am starting to favor smaller, cleaner, and more readable code over the seemingly overkill OO approach. My idea is to now just base everything off the dom using jquery and storing data properties using the .data method. For example, instead of creating an instance of a new Tweet object, you would simply add a div to the dom with class tweet and simply add the properties like author, timestamp, reply to, sent from, etc. in the .data cache for that dom element.
What do you think of this less structured approach when creating instances of things such as items in a stream like twitter? Is OO and prototypal inheritance the best approach or is strict dom manipulation better?
I am doing something similar. I took the OO javascript approach. But instead of using arrays i use a key value object. The key is a unique dom element id, the value is the object itself. it looks something like this.
for example:
var collection = {};
var $domEl = jQuery; // jquery dom element
var myClass= new MyClass($domEl); // class instance
// add to collection
collection[$domEl.attr('id')] = myClass;
// remove
delete collection[$domEl.attr('id')];
Really it depends on the complexity of your objects. A strictly .data approach would need to rely on plugins for all of the related methods, and then store data in the elements data. I have many methods that are not related to strictly element interaction, so i keep the methods and data in the class.
My brain tells me that the very structured Javascript that doesn't rely on the DOM manipulation and calling in and out of it with jQuery would be ideal.
However, I just wrote an HTML5 web app that runs offline using the built in SQLlite and did it using primarily .data and storing information in divs and getting them out of there. It was simple, clean, and easy but for some reason didn't feel right.
But it worked well.
Should I pair every data() call with a later removeData() call?
My assumptions: jQuery's remove() will remove elements from the DOM, and if I don't have any other references to remove, I don't have to do any more clean up.
However, if I have some javascript var or object referring to one of the elements being removed, I'll need to clean that up, and I'm assuming that applies to jQuery's data function, too, because it's referencing the elements somehow.
So if I do need to call removeData before remove, is there a shortcut to remove all data associated with an element or do I have to call each explicitly by name?
Edit: I looked through the source code and confirmed what Borgar and roosteronacid said. Remove takes the elements out of the dom and deletes any events and data stored with them - which is convenient, but makes me wonder when you would use removeData(). Probably not often.
jQuery's data does not keep a reference to the element so that you don't need to worry about memory leaks. Its intended purpose is to solve this exact problem.
A slight simplification of how it works:
An id member is added to each "touched" DOM node. All subsequent actions involving that DOM element use that id.
var theNode = document.getElementById('examplenode');
theNode[ 'jQuery' + timestamp ] = someInternalNodeID;
You can access the id using the same function jQuery uses:
someInternalID = jQuery.data( document.body );
When you append data to the node it stores that on the jQuery object, filed under the node's internal id. Your $(element).data(key,value) translates internally to something like:
jQuery.cache[ someInternalNodeID ][ theKey ] = theValue;
Everything goes into the same structure, including event handlers:
jQuery.cache[ someInternalNodeID ][ 'events' ][ 'click' ] = theHandler;
When an element is removed, jQuery can therefore throw away all the data (and the event handlers) with one simple operation:
delete jQuery.cache[ someInternalNodeID ];
Theoretically, you may therefore also remove jQuery without leaks occurring from any references. jQuery even supports multiple separate instances of the library, each holding it's own set of data or events.
You can see John Resig explaining this stuff in the "The DOM Is a Mess" presentation.
The whole point of jQuery is to abstract away from crappy JavaScript implementations and bugs in browsers.. such as memory leaks :)
.. Yup; all associated data to an element will be removed when that element is removed from the DOM.
By and large, javascript is fairly good about knowing when it's appropriate to collect the garbage, and unless you're writing very large-scale or long-running client-side apps, I'd say the memory involved is mostly inconsequential and trying to second-guess it isn't gonna gain you a lot.
Determining what unfinished lexical closures or other tricky javascript in jQuery might still be accessing your given data could be pretty complicated in some cases.
As far as I'm aware, though, if you store a reference to whatever you got with jQuery's data function then it would continue to exist after the element is removed, so removing that reference would be necessary as well. Some simple test cases would give you a more definite answer.