Talk:ResourceLoader/Core modules

About this board

Archives 

Archive (until 2012)


קיפודנחש (talkcontribs)

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 -

Peter Bowman (talkcontribs)

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

קיפודנחש (talkcontribs)

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.

Peter Bowman (talkcontribs)

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.

Jdforrester (WMF) (talkcontribs)

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.

קיפודנחש (talkcontribs)

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

Ciencia Al Poder (talkcontribs)

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 :)

Reply to "tipsy"
Zes M Young (talkcontribs)

Why is ES6 not supported in Gadgets and UserCommonJS?

Legoktm (talkcontribs)
Reply to "I have a question"

Is there any way to callback after using load?

10
Eduemoni (talkcontribs)

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

Od1n (talkcontribs)

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.

Jack who built the house (talkcontribs)

Won't this work for you?

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

Or even shorter:

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

Od1n (talkcontribs)

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. »

Erutuon (talkcontribs)

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.

Od1n (talkcontribs)

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 :)

Od1n (talkcontribs)

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

Yug (talkcontribs)

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.

Od1n (talkcontribs)

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.

Reply to "Is there any way to callback after using load?"

mw.Api().saveOption() can't change value of hidden gadget option?

2
P.T.Đ (talkcontribs)

Is there any way to do this?

Ciencia Al Poder (talkcontribs)

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

Reply to "mw.Api().saveOption() can't change value of hidden gadget option?"
Jdforrester (WMF) (talkcontribs)

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

Nardog (talkcontribs)

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?

Ciencia Al Poder (talkcontribs)

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

Krinkle (talkcontribs)

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

Reply to "Heading selection"

Could we split the MediaWiki section somewhere?

1
Þjarkur (talkcontribs)

From the article's title it isn't obvious what information is contained here, and the functions of mw are not relevant to ResourceLoader. Wouldn't it be better to split it somewhere, maybe to Manual:JavaScript/mediawiki or Manual:mw? The information is also strangely split between this page and Manual:Interface/JavaScript (an article that could also do with a better name).

Reply to "Could we split the MediaWiki section somewhere?"

Access the API.edit.create function in MediaWiki 1.31.1

4
Summary by Jdforrester (WMF)

mediawiki.api.edit before 1.32.0

FlyDangerousO7 (talkcontribs)

I'm using the following mw.API call:

new mw.Api().create( 'Sandbox', { summary: 'Load sand particles.' }, 'Sand.');


I'm receiving an error: Uncaught TypeError: Cannot read property 'create' of undefined.

I believe that the edit module was a separate module pre-MediaWiki 1.32. I've been searching how to load the 'edit' module and access the create page function, but can't seem to find an example. I also tried to search for a git repository to backtrack the changes, but couldn't find a repository. The following documentation doesn't seem to support any other version of the API except for the newest MediaWiki version: https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Api.plugin.edit


Does someone know how to use the create page function on MediaWiki 1.31.1?


Thank you,

-Don

Od1n (talkcontribs)

Try the following:

if ( mw.loader.getState( 'mediawiki.api.edit' ) !== null ) {
    mw.loader.load( 'mediawiki.api.edit' );
}

The test is to avoid triggering an error on MediaWiki 1.32 and following.

Od1n (talkcontribs)

A more complete snippet:

var moduleApiEdit = ( mw.loader.getState( 'mediawiki.api.edit' ) !== null )
    ? 'mediawiki.api.edit' // MediaWiki before 1.32
    : 'mediawiki.api';     // MediaWiki 1.32+

mw.loader.using( moduleApiEdit, function () {
    // your code
} );
139.169.212.144 (talkcontribs)

That worked exactly as excepted! Thank you for the help. :)

Prtksxna (talkcontribs)

Modules such as mediawiki.feedback and mediawiki.util have documentation both on this page and on jsDuck. Should we remove the one here, link to the API docs, and copy over stuff that is missing there (or these three things in some other order)?

Od1n (talkcontribs)

I was about to post the same thing, about mediawiki.api.* submodules. Documenting the individual methods (mw.Api#isCategory, etc.) here is cluttering, cumbersome, unmaintained and outdated. Whereas we could link to specific API pages (category, etc.) which is simple to do, more convenient to read on jsDuck, and always up-to-date. Ping Krinkle (by the way, I've done a handful of edits on this page today).

Krinkle (talkcontribs)

Yeah, any outdated or duplicated documentation here is fine to remove. I've been doing that for years, but it's a slow process.

If you find any method/class documentation or usage examples that missing from doc.wikimedia.org, they should be added there before removing here.

If you find any migration instructions on this page that are missing from RL/MGU, they should be added there before removing here.

Reply to "Duplicating documentation"
Erutuon (talkcontribs)

I tested this code on Wiktionary and it doesn't work.

Legoktm (talkcontribs)

Can you be more specific about what you tried and what isn't working? I just tested it and it works for me.

Erutuon (talkcontribs)

I copied the code from the above link verbatim into the Wiktionary user script sandbox, and called mw.notify on the return value. Error in the console: Uncaught TypeError: api.parse is not a function.

קיפודנחש (talkcontribs)

note that even though the code says

new mw.Api();

it's not enough to load module mediawiki.api: you need to load mediawiki.api.parse, like so:

1 mw.loader.using( 'mediawiki.api.parse' )
2 .done( function() {
3     new mw.Api().parse( {
4         // like the example.
5     });
6 }); // using..done

note that loading this module, will automatically load its dependencies i.e. mediawiki.api, so you don't have to load it explicitly, though it won't harm anything to do so anyway.

peace.

Erutuon (talkcontribs)

Thanks! That solved the problem. I'm puzzled, because I had loaded mw.api, but the function parse was still not present in the mw.Api object...

קיפודנחש (talkcontribs)

mediawiki.api has several such sub-modules, e.g., edit, watch, options, and some more (and prolly more to come).

each brings some specific set of functions, to make the interaction with specific area of the api more convenient to use.

to use them, you need to load the one you need specifically. loading any of them pulls mediawiki.api with it.

peace.

Collapse and Expand buttons do not show in mw-collapsible

2
Ken Roy (talkcontribs)

I am testing an upgrade of MW from 1.16.5 to 1.23.10. Previously we used ToggleDisplay2 to Collapse or Expand text sections on a page. I am trying to use the jQuery:makeCollapsible replacement, but I am not getting the [Collapse] and [Expand] button links.

What am I doing wrong? Do I need to add anything the MediaWiki:common.js? or to LocalSettings.php for the jQuery:makeCollapsible to work?

Ken Roy (talkcontribs)

This appears to be an issue in the Wikitext/Preview tab only, so I have disabled the WikiEditor preview.

Reply to "Collapse and Expand buttons do not show in mw-collapsible"
Return to "ResourceLoader/Core modules" page.