Page MenuHomePhabricator

Provide public API to know whether an ES6 module can be loaded
Closed, ResolvedPublicFeature


In Vector we'd like to limit the search experience to ES6 browsers. Right now we do this via some feature detection but we have to mirror the mw.loader logic.

We use mw.loader.using to load the module, when I set the es6 flag to true, this Promise will be rejected.

The problem here, is we have an intermediate loading state that shows up while the ResourceLoader module loads, so we can't wait for the response to know whether the module loads, we need to know it before we make the call

Please make this method publically accessible so it can be checked prior to loading code.

This is the code I would like to call:

if ( mw.loader.isES6Supported()  ){
   mw.loader.using('').then( clearLoadingState, clearLoadingState );.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I don't think this should be exposed, but I recognise the user case. I had envisoned the promise returned from using() would suffice, but I realize this signal would be abiguous for your use case and be async whereas you'd want an earlier signal in the case of conditionally displaying a loading spinner.

What if we provide the information through getState()? We can consider a module as unavailable if it's not loadable in the current browser. This would avoid fragile integration of the internal semantics around this, and also make it easier to remove this from core when the time comes without having to update any calling code, allowing for progressive enhancement and a more cleanly separated API.

if ( mw.loader.getState( '' ) ) {

(Note this wouldn't work today since we currently mark the unavailable ES6 module as "registered", I'm proposing to change that.)

Krinkle renamed this task from Make isES6Supported a public API to Provide public API to know whether an ES6 module can be loaded.Jan 20 2022, 6:58 PM
Krinkle triaged this task as High priority.Jan 20 2022, 7:02 PM
Krinkle moved this task from Inbox to Accepted Enhancement on the MediaWiki-ResourceLoader board.

I can open a new ticket for this, but we may want to consider adding a client-es6 class to the body tag to mirror the existing client-js class we have for ES6 scripts that load on startup. I hit a use case, where ES6 code is being loaded on startup that progressively enhances an element only when ES6 is available.

Change 758549 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] resourceloader: Omit ES6-only modules from registry in ES5 context

Change 758549 merged by jenkins-bot:

[mediawiki/core@master] resourceloader: Omit ES6-only modules from registry in ES5 context

Krinkle changed the subtype of this task from "Bug Report" to "Feature Request".Feb 28 2022, 10:48 PM