Prevent multiple inclusions of jQuery UI

[imkingdavid]

If jQuery UI is included multiple times into a page, it can stop working or else work incorrectly. We need to prevent multiple inclusions of the jQuery UI library so that such issues don't come up. The problem is, many extensions will likely need to use jQuery UI.

One proposed solution was

Code: Select all

<script>window.jQuery.ui || document.write('<!-- INCLUDEJS jquery.ui.js -->')</script>

But INCLUDEJS doesn't return in the same location, it just appends the script to an internal array that is later use to add scripts at the bottom of the page. So that doesn't work.

One option, since we're getting an array of files, would be to check filenames. However, this is not practical because the file could be named just about anything.

A second, more drastic option, would be to simply do the same thing we do with jQuery itself and include the jQuery UI library into the core (while also providing the option for it to be loaded via CDN). An argument against this is that there is currently no core template that uses any jQuery UI functionality. However, I think that including the library even when it's not used by the core (yet) is a good idea because of two things:
1) There isn't as much potential for conflicts between extensions
2) If we decide to add some jQuery UI functionality into the style later, we don't have to go through adding the library to the core then.

Of course, since we don't use it already, I'd be okay with simply preventing multiple inclusions if there is a way to do so. Otherwise, I support adding the library to the package.

EDIT: jQuery UI has several components that can be selected when downloading. If we add it to the core, we need to select all available components so that we aren't unnecessarily limiting extension authors.

[Pico88]

+1 for adding jQuery UI to the core.

[MattF]

It should be included with the core, as it can come in many varieties if left up to individual extensions (full build, or specific component builds only). There is no way to manage it if extension authors are allowed to provide it themselves.

Maybe include it with the core, but disabled (via config var) and have extension authors enable its config when installing if they need it in their ext?

However, serving it w/o actually needing it is overkill, considering even minified, the entire jQuery UI is 228kb (smaller I'm sure when gzipped, but not everyone will use it from the CDN or has gzip enabled on their servers).

Hmm, maybe this may be a time to think about using something like require.js to handle script libraries.

Then ext developers would simply define the libraries they need along with their code in something like:

Code: Select all

define(["jquery", "jquery.ui"], function($) {

    //plugin code goes here

    $(function() {
        $('body').alpha().beta();
    });

});

[Jessica.]

+1 for adding it to core

[brunoais]

-1 blindly adding it to the core.

jQuery is mildly expensive in terms of file size and execution when the page loads (part of its feature detection).
jQuery UI is a lot more expensive to do that. If it's expensive then it shouldn't be added just because it might be used.

IMO, we should just add a manifest-like option to extension authors that allows them to request libraries like these.

Another viable options (I don't really like adding more work on the client but it is way better than simply blindly adding jQuery UI) is to use VSE+'s idea about using require.js to do that work.

[Danielx64]

Have anyone looked at how wordpress handle it? The core check to see if it needed then include it once if required.

[Danielx64]

-1 blindly adding it to the core.

jQuery is mildly expensive in terms of file size and execution when the page loads (part of its feature detection).
jQuery UI is a lot more expensive to do that. If it's expensive then it shouldn't be added just because it might be used.

IMO, we should just add a manifest-like option to extension authors that allows them to request libraries like these.

Another viable options (I don't really like adding more work on the client but it is way better than simply blindly adding jQuery UI) is to use VSE+'s idea about using require.js to do that work.

Now it can slow down older computers too right?

[brunoais]

-1 blindly adding it to the core.

jQuery is mildly expensive in terms of file size and execution when the page loads (part of its feature detection).
jQuery UI is a lot more expensive to do that. If it's expensive then it shouldn't be added just because it might be used.

IMO, we should just add a manifest-like option to extension authors that allows them to request libraries like these.

Another viable options (I don't really like adding more work on the client but it is way better than simply blindly adding jQuery UI) is to use VSE+'s idea about using require.js to do that work.

Now it can slow down older computers too right?

That's not the main thing. The main thing is the small battery powered gadgets. Those are underpowered (CPU and/or BUS), probably have access to slower internet and any savings in processing and bandwidth is a "godly" given to make the battery last longer.
Not that those don't matter too, you won't believe what you can find in poorer countries compared to "most" countries.

[imkingdavid]

jQuery UI is a lot more expensive to do that. If it's expensive then it shouldn't be added just because it might be used.

It's not "might be used". I'm already using it in one of my extensions.

IMO, we should just add a manifest-like option to extension authors that allows them to request libraries like these.

Can you describe how this works?

[DavidIQ]

jQuery UI is a lot more expensive to do that. If it's expensive then it shouldn't be added just because it might be used.

It's not "might be used". I'm already using it in one of my extensions.

Extension != core though. If I don't have your extension installed then I don't need jQuery UI in the board. Perhaps there should be some way to enable the use of jQuery UI per extension that needs it instead of always loading it. That way you don't need to worry about including it multiple times. If a style needs it by default then they can simply always use it.