Currently the module 'mediawiki.action.view.postEdit' is loaded on every article views although the module is only needed once directly after an edit and the cookie is set.
Re-opening. Following optimisation work on the mediawiki.notification module from f2e8cd6dbdfc4, it occurred to me the page I was reading did not produce any notifications. We always recommend using mw.notify() which lazy-loads the module on first use. The reason it was loaded is because:
- postEdit.js was changed to depend on mediawiki.notification directly (for its CSS styles) - f8ac9bb2e6a28c0
- VisualEditor's ext.visualEditor.desktopArticleTarget.init module was changed to depend on postEdit - 1e04640d02c9
Given postEdit was especially optimised to only be loaded where needed and yet (when loaded) not require further lazy-loading, it probably doesn't make sense to change postEdit.js. It loading mediawiki.notification at the same time is fine.
We should instead update VisualEditor to not require postEdit as part of its on-every-page-view "init init" module. It's only needed after saving an edit. Loading it as part of the earliest "init" module on every page is a bit too much. I'd recommend removing as dependency from the init-init code and instead loading it in one of the following two ways:
- Move to the list of modules batch loaded at edit-start time within ve.init.mw.ArticleTargetLoader.js. This would delay editor startup, and actually not work for the second case listed below.
- A better optinon: Lazy-load where needed, as part of an existing batch where possible, in the two places it is used:
- DesktopArticleTarget#saveComplete: Can be loaded as part of the mw.loader.load() batch for the page view. The mw.hook call will naturally be handled once it arrived, no using() promise needed.
- DesktopArticleTarget.init#uri.query.venotify: This is the handler for after the case where save has to redirect/refresh (e.g. when creating a page or restoring). It can be specifically preloaded here with a one-off mw.loader.load().