Talk:ResourceLoader/Core modules

Previous page history was archived for backup purposes at Talk:ResourceLoader/Core modules/LQT Archive 1 on 2015-07-10.

Per https://github.com/harvesthq/chosen, jquery.chosen is deprecated. Can Select2 be added as a replacement? It has much of the same functionality, plus the appearance is much more in line with OOUI.

@Ahecht: We're probably going to want to drop it, rather than replace it; it's been unused in production code for a long while, except for any gadgets/scripts.

Possibly hit the site during a deployment; fine now.

https://doc.wikimedia.org/mediawiki-core/master/js/

This page relies heavily on redirecting people to the JS docs but for me it remains stuck on the loading cogwheel. The console displays a 404 error.

It works fine for me. What page / resource is 404ing for you?

Works for me, too

It was broken for me too but fixed itself when I opened the developer console. So some sort of a caching issue I think.

Maybe it was being updated after a deploy, and you just hit the website at that precise moment :)

The documentation link in "#jquery.tablesorter" section is unavailable. Is there a documentation for this module?

I've fixed the link. It points to the source code, which includes some comments with examples.

See also Help:Sorting

Can I use mediawiki-core JS library (mediawiki.*) outside MediaWiki's front-end environment? If possible, what do I need to configure before using it (like to be able to execute a POST request with token)?

Executing POST requests with tokens doesn't need the mediawiki.* library.

Use native XMLHttpRequest objects from JavaScript, or utility libraries like jQuery against the MediaWiki api.

I have a piece of code that's supposed to run every time Wikipedia Recent Changes is (semi)automatically refreshed (live feed / button press on new changes):

$(document).ready(function() {

if (mw.config.get("wgCanonicalSpecialPageName") === "Recentchanges") {

       mw.hook("wikipage.content").add(function (){

            /*...code to move some divs around...*/

            console.log("fired!")

       })

   }

}

This always seems to fire twice. My question is whether "wikipage.content change" applies only to content provided by the server, or does my div-moving-around also count as content change, triggering the hook for the second time. How can one prevent this from happening? Thnx.

You can see how it's done here:

1. sv:MediaWiki:Gadget-TruncateIPv6.js
2. sv:MediaWiki:Gadget-RecentChangesUnpatrolledPages.js
3. sv:MediaWiki:Gadget-RecentChangesSnabbraderingar.js
4. sv:MediaWiki:Gadget-rcexcludeuser.js

Thank you very much, @Nirmos! For reference, this is what needs to be done (from example #4):

a) define a function that needs to be run when the page is loaded and when the mw-changeslist <div> (Recent Changes page) is refreshed:

function fireIt() {
 /*...code to move some divs around...*/
 console.log("fired!")
 }

b) run the function within $(document).ready()

c) set up a mw.hook within $(document).ready() like this

mw.hook("wikipage.content").add( function (element) {
   if ( element.hasClass( 'mw-changeslist' ) ) {
           fireIt();
           }
   });

tipsy was "deprecated" years ago, with no suitable substitute.

current doc recommends using "oojs", but i could not locate any oojs functionality pertaining to tooltips, IOW, no oojs class/object/api which can replace tipsy.

at the very least, i suggest removing this null recommendation from the doc.

if i missed something, and there _si_ some oojs things which can replace tipsy, please provide more precise link in the doc (and in any answer to this post).

thanks, peace -

Please check PopupWidget and other Popup*-prefixed classes (docs).

sorry, but popup is not adequate, or even inadequate, replacement for tipsy.

the main functionality of tipsy is handling the "hover" feature, i.e., responding to "mouseenter/mouseleave" events (with some timers intermingled), handling the display/hide of the tooltip based on mouse pointer location.

popup does not provide any support there, and in order to implement tooltip functionality, the programmer has to reimplement 80% of tipsy code herself, capturing the events and controlling the visibility of the popup.

IOW, popup can't be considered replacement for tipsy.

if i missed some key functionality of popup, and it can actually do some of what tipsy does, i will be very grateful to learn.

peace.

I wouldn't say that implementing said logic is hard, but on the other hand I don't know what your specific requirements are. Here you can find a desktop-oriented gadget that registers hover events for an OOjs-ui tooltip.

Anything relying on hover is fundamentally incompatible with mobile users, who are the majority of readers and a growing portion of editors (albeit still the smaller part). I don't expect there will be a hover-based functionality shipped. Please stop using them.

unfortunately, mobile does not support hover.

that said, wikimedia projects do support "desktop only" features, some of which depend on "hover", e.g. "page preview" and "cite preview" features.

there are other desktop only features, including most project-specific gadgets, and having better tooltip tool is important.

i don't love tipsy, and would like to have a good ooui tool to replace it, so i don't have to re-implement it in each script or gadget that uses tipsy today.

peace

We use Tipsy to provide mobile users with tooltips that are otherwise hidden to them. Instead of displaying a tooltip on hover, the tooltip is displayed when the user touches or taps the text that should display the tooltip.

For example, we have some tooltips created with this code:

<span class="explain" title="This is a tooltip">Text</span>

Desktop already displays a tooltip on hover. On mobile, users can tap the text to display the tooltip thanks to Tipsy. Text marked with class="explain" gets a dotted underline to give users a hint that there's some tooltip there.

The deprecation means it may be removed from MediaWiki core in the future. But I don't mind, because we've gadgetized the tipsy code as to not depend on this core feature. Of course, on a non-WMF wiki :)

Why is ES6 not supported in Gadgets and UserCommonJS?

See T75714.

I am trying to load a js file under my wiki

mw.loader.load( '/w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' );

It loads the Slick jquery plugin, then after loading it I would like to use it as a gadget, where a wildcard number of classes can become a caroussel, however after loading it I am unable to use it, because the module is not loaded yet

You could try the following:

mw.loader.implement( 'HackyCustomModuleRegistration', [ '/w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' ] );
mw.loader.using( 'HackyCustomModuleRegistration', function () {
    // ...
} );

However, the mw.loader.implement() method (code) is missing from the documentation, and is to be considered private.

Won't this work for you?

$.getScript( 'https://.../w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' ).done( function () {
    // your code
} );

Or even shorter:

$.getScript( 'https://.../w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript', function () {
    // runs if loading was successful
} );

I thought it was a better solution… but from the jQuery.getScript() documentation (emphasis mine):

« The callback is fired once the script has been loaded but not necessarily executed. »

So if $.getScript(url, func) doesn't necessarily run the script before calling func, is the script run before func with $.getScript(url).done(func) or with the mw.loader version? I've used the $.getScript version that I posted without considering this issue; for whatever reason it worked fine.

Digging inside the code of module mediawiki (and mediawiki.base), I found out the "load+execute script, then callback" code is actually very simple, see:

function addScript( src, callback ) {
    var script = document.createElement( 'script' );
    script.src = src;
    script.onload = script.onerror = function () {
        if ( script.parentNode ) {
            script.parentNode.removeChild( script );
        }
        script = null;
        if ( callback ) {
            callback();
            callback = null;
        }
    };
    document.head.appendChild( script );
}

A few notes about the code:

• The two = null are for performance, to free memory (otherwise the objects would stay in memory forever)
• The onerror event is not for request error, but for script execution error

So, I think the best solution would be to reuse the above snippet as standalone. Lightweight, no dependency of any kind :)

For the sake of refs'ing, this implementation has been introduced in this commit (T192623).

I also tried with asynch, await and .then() but I was informed that [As of April 2021] the JS syntax checker blocks use of ES6 in (i) gadgets, (ii) sitewide JS pages and (iii) user common.js page. So no `await` in `MediaWiki:Common.js`.

I would like to load into `MediaWiki:Common.js` 3 data from pages [MediaWiki:dataA.js], [MediaWiki:dataA.js], [MediaWiki:dataA.js] , then process these data. Clean, merge. Then create a dataviz. I need it to be sequential but I'm still not clear how to do so. As of now, this data are still undefined when my clean, merge, and dataviz code runs.

As for this ES6 issue, there is a hack consisting in storing the ES6 in the User namespace (ex: `User:.../something.js`), then you can use mw.loader.load() and it somehow work.

You may also use mw.loader.getScript() (which, contrarily to jQuery.getScript(), wait for the loaded JavaScript to be executed):

mw.loader.getScript( '/w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' ).then( function () {
    /* Callback */
} );

Internally, it uses jQuery.ajax(), just tweaking the options so that the HTTP cache is re-enabled. I had a look at jQuery source code some time ago, to confirm it is executing the loaded JavaScript before triggering the promise.

Is there any way to do this?

No. Hidden gadgets can't be enabled/disabled in preferences. That's the whole point of hidden gadgets after all.

Rather than @Nardog edit-warring, I'd invite them to explain and discuss why they want to re-design this page with its maintainers. :-)

I just did, and you're the one who reverted it without explaining why.

The current TOC is highly user-hostile. There's not even a way to see the list of methods each module has.

Do you genuinely think it's superior? If so, care to explain?

I actually like the display of 2 levels of headings instead of 1, to quickly jump to the relevant section. TOC is already floated to the right, so it's not very intrusive this way

This page does not provide a list of methods. That's what the API documentation is for.