Skip to main content

Bug Tracker

Side navigation

#10033 closed enhancement (wontfix)

Opened August 11, 2011 11:07PM UTC

Closed August 11, 2011 11:52PM UTC

Last modified August 26, 2011 01:34AM UTC

Why Doesn't JQuery Expose its UUID Functionality?

Reported by: cmoschini Owned by:
Priority: low Milestone:
Component: core Version: 1.6.2
Keywords: Cc:
Blocked by: Blocking:

(I originally asked this on StackOverflow, and was recommended I just ask in the form of a bug ticket).

JQuery uses the $.data(tag, name, value) to store data in a map keyed off of the tag[jQuery.expando] which in turn is set to a number based on jQuery.uuid. It does this to avoid memory leaks.

While $.data() is very useful, there are times you want to map data to tags without dumping that data into one global bucket - you want your own smaller bucket of data that you can, for example, check the length of or loop through.

As a contrived example, suppose you have icons that rotate through one of 4 states when clicked. When one is in state 2, you want to add it to an array of icons in state 2. The most obvious way to do so is to add the tag to an array; however doing so would create a memory leak. You could call $.data() on the icon, but that doesn't quite accomplish what you're trying to do - you'd have to loop through all the icons checking $.data() against them to figure out which are and aren't in the list.

You need to store some abstraction of the tags in an array, and that's jQuery's UUIDs. You could write your own UUID functionality, but ideally you just leverage the UUID functionality already built-in to JQuery for both code-size and quality reasons. You could ask JQuery to attach a UUID to the tag implicitly by calling $.data(tag, 'irrelevant', 1) and then check tag[jQuery.expando] to get its UUID, and finally use that in the list... but that's a bit of a hack. Really what would be ideal is to have the following exposed in the public API:

$.getUuid(tag): Checks for and creates a UUID if none exists - ideally the method is factored out of $.data() and creates or fetches the uuid for the tag passed in.

So, is there a reason this isn't factored out into its own method in jQuery? Is this harmful in some way? Was it just never something that seemed useful?

I should note that I've actually factored it out in the version of jQuery we're using, and it's very helpful. But perhaps there's an underlying risk I'm not hitting in my usage. I'm also aware of a plugin that sort-of accomplishes this, but it's a bit broken - and having 2 codepaths to perform the same UUID functionality is both a bit wasteful and a bit brittle.

Attachments (0)
Change History (5)

Changed August 11, 2011 11:52PM UTC by rwaldron comment:1

component: unfiledcore
milestone: None1.6.3
priority: undecidedlow
resolution: → wontfix
status: newclosed

jQuery.uuid and jQuery.expando are internal properties that are absolutely not meant to be used by any code other then jQuery core.

Changed August 12, 2011 12:03AM UTC by cmoschini comment:2

Replying to [comment:1 rwaldron]:

jQuery.uuid and jQuery.expando are internal properties that are absolutely not meant to be used by any code other then jQuery core.

I realize that may not have been the intention when the code was originally written, but the uuid functionality is very useful and widely used throughout jQuery to work around browser memory leaks. It's also well-tested. It's much more valuable to reuse than to just go off writing my own solution, or 10000 jquery users going off and each writing their own.

I'd like to see this as a future feature rather than just closed and forgotten.

Changed August 12, 2011 12:58AM UTC by rwaldron comment:3

10,000? More like 24.6 Million.

How many tickets are asking for built in uuid function? 1.

If this was a feature that was frequently requested, then I could see the potential for opening up discussion, but as it's not, then there is no discussion to have. If you're interested in forcing us to have a discussion about it, follow for updates about jQuery 1.8 call for proposals. We closed 1.7 feature requests around May 23rd and 1.7 will be released in October. A call for proposals, re: 1.8, will likely be sometime around the new year.

Changed August 12, 2011 01:10AM UTC by dmethvin comment:4

What's wrong with just incrementing your own counter anyway? If we expose more internal functionality it just creates another thing we are unable to change when an optimization opportunity presents itself.

Changed August 26, 2011 01:34AM UTC by dmethvin comment:5

milestone: 1.6.3