jQuery clashes

[aaugustin]

I'm creating a new issue to track in a single place all the problems related to the way the Debug Toolbar inserts jQuery into the page.
#440 was supposed to fix the problem, but it didn't work for the trivial case of an HTML page without any JavaScript.

I went for a very dumb solution in 2b6f5d6. I don't know any better and I'm unable to assess the solutions that have been offered.

As a consequence, until the other maintainers have a look at this issue or the toolbar gains new maintainers, this issue is unlikely to move forwards.

I will now close all the issues that are variations of this issue as duplicates.

[BertrandBordage]

What about embedding jQuery inside a variable? Django admin does this, it then accesses jQuery using django.jQuery instead of jQuery or $. I know that supposes having jQuery loaded twice most of the time, but that's only for debug…

[aaugustin]

Yes, that would make sense.

How would it interact with the AMD stuff?

[djfarrelly]

The modified jQuery would have to have a different name also in it's define call. ex: define('toolbar.jquery') to make sure it doesn't clash with other versions of jQuery. In essence, changing the variable is very similar to what was in place before #440, with jQuery.noConflict(true) still functioning.

Note: This wouldn't fix the issue with AMD referenced in #506, that's a separate issue from this one.

[carltongibson]

I quite like the solution in 2b6f5d6. I worry that other solutions are trying to do too much.

How about a setting, defaulting to True, USE_DEBUG_TOOLBAR_PROVIDED_JQUERY or such? Developers could turn this off if/when they're bundling their own jQuery (however they choose to do that).

(I wonder about overriding per-view, but I suspect that's too clever too.)

[jeffbowen]

+1 to having DDT either have a uniquely named version of jQuery (like @djfarrelly suggests) or a setting to disable DDT from including jQuery (like @carltongibson suggests). The way it works now is causing conflicts when I try to use RequireJS.

[stebunovd]

+1 to uniquely named version of jQuery. This solution seem to be less error prone, because DDT will always use the same known version of jQuery. Use of external jQuery may potentially lead to issues related with incompatible jQuery version.

[aaugustin]

@jeffbowen Could you explain "is causing conflicts"?

@stebunovd How would that interact with AMD?

It find it extremely depressing that all your comments sound there's a very easy solution, yet no one submits a pull request or even a code sample. I know I'm dumb, especially when it comes to frontend stuff. Will anyone please help? Can you all assume I have never written a single line of JavaScript when you talk to me?

Reading carefully your comments, I suspect that:

• half of you are trying to use RequireJS and would like the DDT to stop inserting jQuery into the page;
• the other half aren't using RequireJS and wondering why I'm bothering with this mess (I'm wondering too).

From now on, f you want to make an useful comment on this ticket, please consider both use cases. Thank you.

---

I spent some time this morning trying to write a patch to use a uniquely named version of jQuery, but I can't figure out how it's supposed to work with AMD.

Here's where I am:

<script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js"></script>
<script>var djdt = {}; djdt.jQuery = jQuery.noConflict(true);</script>

--> This loads a separate jQuery and makes it available in djdt.jQuery. We should take care to preserve it when overriding the global djdt variable in toolbar.js. But is it compatible with AMD / RequireJS?

Then each toolbar.<panel>.js file contains this piece of code:

(function (factory) {
    if (typeof define === 'function' && define.amd) {
        define(['jquery'], factory); // what does 'jquery' refer to here?
    } else {
        factory(jQuery);  // should be changed to djdt.jQuery
    }
}(function ($) {

    // code here 

}));

--> Can anyone answer the question I added in comment? How can I test that it works as expected?

---

tl;dr What's the proper implementation of RequireJS in our use case? Does anyone on Earth actually know how AMD and RequireJS work? Should I simply revert everything @singingwolfboy did and declare AMD and RequireJS as unsupported?

@robhudson @jezdez @dcramer Do you have any insights on this issue? I'm feeling extremely lonely...