Followup to T227160: Investigate whether WhoWroteThat browser extension can have access to the `window` global on MediaWiki sites, in order to make development work streamlined and be able to use MediaWiki's tools and existing UX, WhoWroteThat's code can be injected into the DOM and act as a sort of gadget, which means we can have access to the window.mw global variable, and with it, everything that the mw.loader provides.

Because of timing issues, and to provide lazy-loading for the bulk of the code, we will need to split the code to general two parts:

• On document ready, but before mw.loader.using is available, we can attach the toggle button of the WhoWroteThat engine to the DOM
• That script will be added to resource-loader's RLQ which will load jQuery and mediawiki.base dependencies
• On click of that button, lazy-load ooui and whatever other dependencies we need with mw.loader.using which will be available to us after RLQ finishes.

The working code itself can be split into its different classes and objects so it can be unit-tested. A build step can then be implemented to combine the working code into a single script that the browser extension will then inject into the DOM.

From the investigation conclusion, here is the action plan:

Action plan

• The WhoWroteThat script can be written as if it is running from within MW infrastructure (just like a gadget)
• Our build step (currently using grunt, in the extension repo, but may change to use another tool) needs to do this:
  • Concatenate all WhoWroteThat business-logic files into a single script, with two parts:
    • a loader script: This attaches whatever trigger button we need on the page to activate the WhoWroteThat mode. This depends on jquery and mediawiki.base
    • Business logic: The entire logic of presenting the results from Whocolor, popups, etc. This depends on OOUI.
  • The "business logic" script can be wrapped with a mw.loader.using( 'ooui' ).then( ... ) statement, and then be included inside the loader script.
  • The loader (that includes, within it, a lazy-loaded business-logic script) will be wrapped by a loading method.
  • At the bottom of the concatenated file that has the loading function, we push the loading function into RLQ.
    • We only need the jquery and mediawiki.base dependencies through the RLQ load.
    • When the script sent to the RLQ runs, we have mw.loader.using available, so we can load the heavier dependencies only when we need them (when the toggle button is activated)
• The entire file that was produced is our "web_accessible_resources" and is the file that the extension the injects into the DOM on Wikipedia sites that work with WhoColor

If this looks good and I didn't miss anything, I'll add some code snippets and put this up in the task description, so we can reference to it from our implementation tasks.

Here's what it should look like, generally:

function loadWhoWroteThat() {
	var $button = $( <a> ); // etc

	// CODE: Attach a toggle button somewhere in the DOM. jQuery is available.

	$button.click( function () {
		mw.loader.using( [ 'oojs-ui' ] ).then( function () {


			// CODE: This is handling the actual business logic of WhoWroteThat? service
			// pulling the API from WhoColor, replacing/toggling the new DOM, building
			// OOUI popups for viewing data about revisions, etc.

		} );
	
	} );
}

var q = window.RLQ || ( window.RLQ = [] );
q.push( [ [ 'jquery', 'mediawiki.base' ], loadWhoWroteThat ] );

Since this is the basic structure, our build step can allow us to work with individual files in development (meaning also allowing for proper unit tests, etc) and then build the files into the above structure.