Skip to main content

Bug Tracker

Side navigation

#5880 closed feature (duplicate)

Opened January 20, 2010 08:01PM UTC

Closed February 22, 2011 12:28PM UTC

Last modified February 24, 2011 06:49PM UTC

Method to create a copy of jQuery

Reported by: shadedecho Owned by:
Priority: low Milestone: 1.5
Component: core Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:

For those of us who work with including jQuery (along with a mashup/widget) into abritrary pages that we don't necessarily control, having "jQuery.noConflict()" is absolutely awesome. However, there's a use case that I've run into a few times now, which is, sometimes you might need to create a sandbox'd copy/clone of jQuery (for the purposes of adding in plugins for instance), that remains separate from the existing copy of jQuery that might be on the page.

Apparently some have explored ways to create a clone of the jQuery object, but what it comes down to is that there are some private pieces of data which are held up in the closure that the jQuery function creates, which cannot be separated as it is currently. So, it's not possible to create a totally (only mostly) separate copy of jQuery from an existing instance.

The trick I'm currently using, which is a little brittle and ugly, is to search the DOM looking for the script tag that loaded jQuery (only if it matches a regex with "jquery.js" or some variation thereof in it)... if the script is found, then a new script element is created with the same source URL, which should re-request jQuery (from the cache hopefully!) and then re-execute jQuery.

Then, a jQuery.noConflict(true) call will roll back to the original copy of jQuery and the new sandboxed copy can be saved and used.

The worst part about this hack is the brittleness of having to assume that jQuery comes in its own script file, and that the name is something predictable. Secondarily, having to modify the DOM (even just a script tag) is less than desirable. But it seems to work in most cases.

So, my request is, that we get a new core function, like $.clone (not $.fn.clone), that will in some way re-execute jQuery and create a new closure and new object instance, returning that sandbox'd copy for later use.

Attachments (0)
Change History (7)

Changed November 20, 2010 02:50PM UTC by dmethvin comment:1

keywords: → needsreview
milestone: 1.4.1
status: newopen
summary: a $/jQuery core "clone" functionMethod to create a copy of jQuery

I am not understanding the use case for this from the description, so I'm marking it for review.

Changed November 20, 2010 05:40PM UTC by shadedecho comment:2

So, basically, if you want to have multiple copies of jQuery on the same page (and by copies, I don't just mean references), because for instance you may need to use plugins that conflict, or you may just want to sandbox away some copy of jQuery and prevent changes to that copy from affecting jQuery on the rest of the page.

We have noConflict() which can roll back the global jQuery references, but to create multiple jQuery copies with noConflict() you actually have to load jQuery a second or third time. It would be more preferable if you could just take an existing jQuery instance, and call $.clone() on it to get a new re-executed closure. That way, you'd have two entirely separate copies of jQuery without needing to load the script a second time.

As I said before, this is primarily useful in the mashup case where you load a widget onto a page that loads its own copy of jQuery, and you want to be able to keep that copy separate and sandboxed from the existing instnace. That way, if the page your widget is loaded onto already has jQuery, and several plugins loaded onto it, you can get a fresh clean copy of jQuery that your widget can modify and not affect the rest of the page.

My thought on how to accomplish this is to have the entire jQuery inside a named self-executing function (which establishes the main closure for the jQuery instance), and then the clone() function could call that named closure function a second time to generate a new copy of jQuery and return the result.

Changed February 22, 2011 10:21AM UTC by gnarf comment:3

Is it just me or does complete this?

Changed February 22, 2011 12:28PM UTC by jitter comment:4

keywords: needsreview
milestone: → 1.5
priority: minorlow
resolution: → duplicate
status: openclosed

A first step in this direction has been taken with jQuery.sub although it is different from a completely new loaded version of jQuery. Some further enhancements to jQuery.sub are planned for 1.6

Changed February 22, 2011 12:28PM UTC by jitter comment:5

Duplicate of #7979.

Changed February 22, 2011 01:08PM UTC by shadedecho comment:6

If I load a widget onto a page that already has jquery, and my widget wants to use a pristine/fresh copy of jquery, and so it tries to subclass the existing jquery... doesn't that mean that it'll just create a copy of the jquery as it exists then (which may already be extended and not pristine)?

The spirit of my request was to be able to get a pristine fresh copy of jQuery from any jQuery, regardless of its current state.

Perhaps I'm misunderstanding the future plans for sub() but I think it's not giving what this ticket is asking for.

Changed February 24, 2011 06:49PM UTC by scottgonzalez comment:7

Replying to [comment:6 shadedecho]:

Perhaps I'm misunderstanding the future plans for sub() but I think it's not giving what this ticket is asking for.

Yes, this seems to be outside of the scope for jQuery.subClass() (at least based on current plans). Perhaps this could be implemented via jQuery.subClass( true ) or something similar, but this ticket should remain open as it is not a duplicate of #7979.