Page MenuHomePhabricator

Watchlist Expiry: Perf follow-up 2020
Closed, ResolvedPublic

Description

Tracking task for misc perf follow-up based on how the various last minute changes ended up possibly not in sync with current best practices.

Todo

  1. Remove mediawiki.action.edit.watchlistExpiry module. T274688
  2. Address unstable mw.msg() call.
  3. Address inefficient mw.loader.load() duplicate preload requests.

Prior work

Event Timeline

Change 588837 merged by jenkins-bot:
[mediawiki/core@master] Add watchlist expiry to edit form

https://gerrit.wikimedia.org/r/c/mediawiki/core/ /588837

This change introduces a new top-level bundle entry point for what appears to be a small amount of code to simply load on an existing experience (the edit screen). This should be added to an existing bundle instead.

See also:

Change 649463 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] mediawiki.action.edit: Move module files to their own subdirectory

https://gerrit.wikimedia.org/r/649463

Change 597145 merged by jenkins-bot:
[mediawiki/core@master] Display remaining watch period in watchstar

https://gerrit.wikimedia.org/r/597145

This commit introduces a call to mw.msg() where a message parameter is set to null which is invalid both as regular paramter, but also invalid as plural value (which expects integer). This makes the code difficult to understand, and seems to only work by accident (tech debt) where it is never used in the message passed from alternate conditions.

I suggest either using a real integer as default and thus trust your own code not to use it (instead of the unsupported reliance for mw.msg to never step on it), or to structure the code to acknowledge this split and call the function differently based on the feature being enabled or not.

	daysLeftExpiry = null,

			.attr( 'title', mw.msg( 'tooltip-ca-' + tooltipAction, daysLeftExpiry ) )

  

	function updateWatchLink( $link, action, state, expiry ) {

		if ( expiry === undefined ) {
			expiry = null;
		}
		
	}

	updateWatchLink( $link, action, 'loading', null );

As a general principle, we rarely if ever use the null in our JavaScript codebases, so that can be a good indicator for something that stands out as odd.

Gerrit:

This introduces a second HTTP request for preloading instead of adding to the existing one.

Note that mw.loader.load() accepts an array. I suggest using that, e.g. if … load [ ,, ] else load [ , ] .

Gerrit:

Minor nit pick: There seems to be a lazy-load pattern here around watchlistPopup !=| new WatchlistExpiryWidget but without any use of it. Possibly a left-over from a previous approach that was abandoned?

Change 649463 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.action.edit: Move module files to their own subdirectory

https://gerrit.wikimedia.org/r/649463

Change 654300 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/core@master] mediawiki.page.watch.ajax: consolidate loading of modules

https://gerrit.wikimedia.org/r/654300

Change 654300 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.page.watch.ajax: consolidate loading of modules

https://gerrit.wikimedia.org/r/654300

Krinkle claimed this task.
  • Remove mediawiki.action.edit.watchlistExpiry module.
  • Address inefficient mw.loader.load() duplicate preload requests.

I've fixed these since (mostly via T274688).

  • Address unstable mw.msg() call.

This isn't a perf concern. I raised it as a bug here, but it's not of special concern to me if it's working. It might cause issues later on, but the maintainers/owners can deal with this at their own discretion.

Krinkle renamed this task from Perf follow-up: Watchlist Expiry to Watchlist Expiry: Perf follow-up 2020.Oct 3 2022, 9:32 PM
Krinkle triaged this task as Medium priority.