Currently MobileFrontend(Minerva) has various [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/tree/master/resources | starter modules ]].
They are arranged by feature or page.
For instance if the user cannot watch a certain page we do not load the module skins.minerva.watchstar
After discussing this as a team we concluded that we would prefer to group these by page and move this logic into frontend code. This will mean more JS is loaded by default, but there will be less fragmentation across pages.
To start with the following modules will be merged into a single starter module `skins.minerva.scripts` which will be renamed `skins.minerva.page`
= A/C
== Folder restructure
[] Merge the following modules into one single entry module:
* skins.minerva.scripts
* skins.minerva.scripts.top
* skins.minerva.tablet.scripts
* skins.minerva.notifications
* skins.minerva.newusers
* skins.minerva.fontchanger
* skins.minerva.editor
* skins.minerva.categories
* skins.minerva.backtotop
* skins.minerva.talk
* skins.minerva.toggling
* skins.minerva.watchstar
Use [[ https://gist.github.com/jdlrobson/b462874666c47dbd1ea1aaf25bb85b45 | this script ]] to ensure we do not break the experience for cached HTML
= Loading the new stable features code
[] Add `skins.minerva.page` to any page which is not a SpecialPage.
[] Update the directory structure so all files are listed under skins.minerva.page (rename any init files)
[] The logic inside getContextSpecificModules should be moved from the server side to the client.
[] Inside SkinMinerva->getContextSpecificModules we check if a page is watchable with SkinMinerva->isAllowedPageAction. Move that check to the client - into the file that was previously skins.minerva.watchstar/init.js
[] Inside SkinMinerva->getContextSpecificModules we check if a page has Echo installed and the user is logged in. Move that check to the client - into the file that was previously skins.minerva.notifications/init.js
[] Inside SkinMinerva->getContextSpecificModules we check query string parameters and load the newusers module if necessary. Move that check to the client - into the file that was skins.minerva.newusers/init.js
[] Inside SkinMinerva->getContextSpecificModules we only load talk page code if a page allows talking and the page is wikitext.
== More complicated module moves
[] Toggling code is loaded inside SkinMinerva->getDefaultModules.
[] Inside SkinMinerva->getContextSpecificModules we check if a page is editable with SkinMinerva->isCurrentPageContentModelEditable. Move that check to the client - into the file that was previously skins.minerva.editor/init.js
[] Inside SkinMinerva->getContextSpecificModules we load back top, font changer or categories if enabled. Now we must rely on client side code - add config variables inside SkinMinerva::getSkinConfigVariables and move the logic for these checks into the corresponding client side code.
= Test plan
[] The entry points should load without errors under the following circumstances
* MobileFormatter is not available e.g. useformat=desktop&useskin=minerva (impacts toggling)
* A feature is disabled (for example...):
** if categories is disabled the categories code should not work
** if talk is disabled the talk code should not work
** if back to top is disabled back to top should not work
== Developer notes
[] Rename skins.minerva.scripts to skins.minerva.page and make sure an alias is left (with single dependency) to deal with cached HTML.
[] Any entry point that loads in stable/anon must have an alias to avoid JS errors in cached HTML
[] Document any increase in JS bytes before merging.
[] ~~Please take this opportunity to follow up with patchsets that shift more logic into the generic modules e.g. mobile.toggling, provided that they remain testable and without side effect~~~ don't do this. Keep scope small.
= Open questions
[] How do we check content model on the client? Is there any existing config option or do we need to surface our own?
[] Can we detect whether content has been mobile formatted on the client when deciding to run the toggling code?
[] Is not grouping by feature ever a bad thing?
[] Is a tablet page different from a normal page?
[] What are the benefits of grouping feature (if any)?
[] What implications does this have for code that we load via mw.loader.using from MobileFrontend ? Any?
= Sign off checklist
[] How did this impact [[ https://grafana.wikimedia.org/dashboard/db/mobile-2g | performance ]] in particular first paint / bytes shipped
[] Create cleanup task to remove aliases in a week
[] Update status of T173454