Any element that has either being created or is passed on through a selector, gets assigned a property
uid, which is incremental and unique. Since MooTools 1.4.2, this is only readable via
Slick.uidOf(node) and not via the old element attr
.uid. You can now use the new
uniqueNumber property of any MooTools Element object.
How is that being used? For starters, Element Storage. It relies on the uid as the key in the
Storage object inside a closure, which will have anything you have
.store’d for that element.
Storage[Slick.uidOf(element)].foo = 'bar';
element.retrieve('foo'); // getter of the storage key element.eliminate('foo'); // delete Storage[Slick.uidOf(element)].foo
Initializing storage for an element you have created externally, eg, via
var foo = document.createElement(‘div’) and not Element constructor
Slick.uidOf(foo); // makes it compatible with Storage // same as: document.id(foo);
Things that are stored by the framework into Storage also include all
Fx instances (tween, morph etc) and so forth.
What can you do knowing the UIDs of elements? Well, cloning an element does NOT get the element’s storage or events. You can actually write a new
Element.cloneWithStorage prototype that will also copy all of the stored values you may have, which is useful upto a point – instances that reference a particular element (such as,
Fx.Tween) will continue referencing the old element, so it may have unexpected results. This can be useful in moving your own storage, though, all you need is a similar method that will record what you have stored and allow you to clone it.
Example Storage puncture of another Element’s data:
var foo = new Element('div'), uid = foo.uniqueNumber; foo.store('foo', 'foo only'); var bar = new Element('div'); console.log(bar.retrieve('foo')); // null bar.uniqueNumber = uid; // force overwrite of uid to the other el console.log(bar.retrieve('foo')); // foo only - OH NOES console.log(Object.keys(foo)); // ["uniqueNumber"] - oh dear. enumerable!