Right after saving an edit is a very important point of interaction with the user. This is the natural time to explain how the community reviews edits, to possibly warn about wiki-specific features like FlaggedRevs hiding the edit suggest more tasks, to explain about watchlists, to suggest more editing tasks etc. But in MediaWiki it's under-utilized because the support for it is so poor. #GrowthExperiments does a bucket of hacks to mostly make it work but that really shouldn't be necessary.
There is a Javascript hook that usually fires after edits (`postEdit` or `postEditMobile`) but it's borderline useless:
* Some editors immediately reload the page after calling the hook, so it can't be used for user interaction.
* As it's a Javascript hook, the hook handler needs to be loaded already, which requires a different mechanism for different editors.
* The desktop and mobile hooks get different data, and the data is not super useful in either case (doesn't contain much information about the edit).
There are six significantly different major code paths (not counting extensions not used on Wikimedia wikis, popular editing gadgets etc) that need to be accounted for in a postEdit hook handler:
# Desktop wikitext editor: does a post-redirect-get on save, uses a [[https://gerrit.wikimedia.org/g/mediawiki/core/+/e4afefd8ec029e2b75a18df70a762d75c21fc7ea/includes/page/Article.php#572|cookie hack]] to pass some state through the redirect, sets the `wgPostEdit` JS variable and uses that to fire the `postEdit` hook. On the server side, can be detected [[https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+/2a26f9b518aec71a11101cd092f72e3f061e9d35/includes/WelcomeSurveyHooks.php#163|in a hacky way]] on the server side.
* VisualEditor when the page is newly created, there was a wikitext -> VE switchover, or the editor was opened in some weird place (such as the page history): saves via its own API, fires `postEdit`, then reloads the page. Adds (and after the reload hides) a `venotify` query parameter which makes this detectable on the server side.
* VisualEditor when none of the above is true: saves via its own API, tears down the editor and replaces page content without a reload, then fires `postEdit`. The VisalEditor API that's used for saving the edit provides some integration options which can be used to interact with this event on the server side, somewhat.
* MobileFrontend wikitext editor: saves via the `action=edit` API, fires the `postEditMobile` hook, then immediately triggers a page reload. Unlike `postEdit` this also gets called on a null edit, and passes data that allows differentiating that.
* VisualEditor in MobileFrontend overlay: saves via the VisualEditor API, tears down the editor, fires the `postEditMobile` hook, then changes the URL fragment but does not reload/navigate away.
* VisualEditor in MobileFrontend overlay when creating a new page (but //not// when switching from wikitext to visual editor): saves via the VisualEditor API, tears down the editor, fires the `postEditMobile` hook, then changes the URL fragment. Then reloads the page with a `venotify` query parameter added. (Unlike the desktop case, it does not get hidden away.)
(There are two more code paths via Flow and DiscussionTools if one also cares about talk page edits, and one more for ProofreadPage pages.)
This is very sad. There should be a single JS hook that
* reliably supports user interaction, either by only being called after reload if there's a reload, or by using a promise to delay reload;
* supports a single reliable way to configure that some ResoureLoader module should get loaded to handle the hook (maybe by providing a PHP hook that can examine the edit and decide what JS module needs to be loaded);
* provides a reasonable amount of data about the edit.