Change Details

= skin.minerva prefixed modules We have a pattern in MobileFrontend where we include starter modules such as `skins.minerva.backtotop` and `skins.minerva.newuser` that do something on page load. We also have a mega starter module `skins.minerva.scripts` that does multiple things on page load. What should we do so that we don't have a long list of modules like above? Now that feature flagging is in action, we should consider alternative solutions. Since these scripts don't usually weigh a lot, should we consider loading them in the front end unconditionally and executing them depending on the feature flag. This would also help us clean up SkinMinerva.php that loads modules conditionally, thus reducing cache splits. Note that on startup we load the following modules: * skins.minerva.editor * skins.minerva.fontchanger * skins.minerva.notifications * skins.minerva.scripts * skins.minerva.scripts.top * skins.minerva.tablet.scripts * skins.minerva.talk * skins.minerva.toggling * skins.minerva.watchstar = mobile. prefixed modules Currently we load the following non ResourceLoaderImage modules on startup. Given they are loaded by default it's possible it may be advantageous to package these in a single module (size of startup module/size of resulting JS may be smaller/remove fragmentation of JS files used across pages). We should investigate. Modules: * mobile.betaoptin * mobile.editor.api * mobile.issues * mobile.mainMenu * mobile.pagelist.scripts * mobile.references * mobile.references.gateway * mobile.search * mobile.search.util * mobile.startup * mobile.toc * mobile.toggle * mobile.watchstar = deferring the load of code (was T131082) It seems we can make various savings in the JavaScript we load initially by avoiding loading any modules which depend on `mobile.overlays` at the cost of [[ https://gerrit.wikimedia.org/r/#/c/278204/ | loading code for search and page issues ]] and disentangling the [[ https://gerrit.wikimedia.org/r/278205 | LoadingOverlay and moduleLoader ]] from the overlay module. This could cut initial JavaScript by 10kb at the cost of a potential delay in using search for users visiting for the first time. Is there benefit in doing this? = Discussed questions The following questions were discussed directly/indirectly: * Why is the existing architecture the way it is? * Does it still make sense? * Can skins.minerva.scripts.top and skins.minerva.scripts be merged after recent RL changes? Is there any advantage to having them separate? * On what pages does the script url differ (e.g. where do we load different JavaScript based on context.. do we only load toggling code on main namespace - if so what disadvantage does that have on client side caching/load time of subsequent page loads? Outcome: T167713 = Questions to answer: * Which modules have side effects (e.g. when loaded make changes to the current page) * Which modules are used by 2 or more features? * What are the advantages to merging modules? * What are the advantages of deferring the loading of code * Should modules define features or components? * What code is used outside MobileFrontend? Is there justification for sharing it via its own ResourceLoader module?

How should we organize and manage ResourceLoader modules across our projects, learning from MobileFrontend and Minerva for Vector? = Questions to answer: * Which modules have side effects (e.g. when loaded make changes to the current page) * Which modules are used by 2 or more features? * What are the advantages to merging modules? * What are the advantages of deferring the loading of code? * What do we load on page load? * What code do we defer the loading of? * How we bundle defer code?

= skin.minerva prefixed modulesHow should we organize and manage ResourceLoader modules across our projects, learning from MobileFrontend and Minerva for Vector? We have a pattern in MobileFrontend where we include starter modules such as `skins.minerva.backtotop` and `skins.minerva.newuser` that do something on page load. We also have a mega starter module `skins.minerva.scripts` that does multiple things on page load. What should we do so that we don't have a long list of modules like above? Now that feature flagging is in action, we should consider alternative solutions. Since these scripts don't usually weigh a lot, should we consider loading them in the front end unconditionally and executing them depending on the feature flag. This would also help us clean up SkinMinerva.php that loads modules conditionally, thus reducing cache splits. Note that on startup we load the following modules: * skins.minerva.editor * skins.minerva.fontchanger * skins.minerva.notifications * skins.minerva.scripts * skins.minerva.scripts.top * skins.minerva.tablet.scripts * skins.minerva.talk * skins.minerva.toggling * skins.minerva.watchstar = mobile. prefixed modules Currently we load the following non ResourceLoaderImage modules on startup. Given they are loaded by default it's possible it may be advantageous to package these in a single module (size of startup module/size of resulting JS may be smaller/remove fragmentation of JS files used across pages). We should investigate. Modules: * mobile.betaoptin * mobile.editor.api * mobile.issues * mobile.mainMenu * mobile.pagelist.scripts * mobile.references * mobile.references.gateway * mobile.search * mobile.search.util * mobile.startup * mobile.toc * mobile.toggle * mobile.watchstar = deferring the load of code (was T131082) It seems we can make various savings in the JavaScript we load initially by avoiding loading any modules which depend on `mobile.overlays` at the cost of [[ https://gerrit.wikimedia.org/r/#/c/278204/ | loading code for search and page issues ]] and disentangling the [[ https://gerrit.wikimedia.org/r/278205 | LoadingOverlay and moduleLoader ]] from the overlay module. This could cut initial JavaScript by 10kb at the cost of a potential delay in using search for users visiting for the first time. Is there benefit in doing this? = Discussed questions The following questions were discussed directly/indirectly: * Why is the existing architecture the way it is? * Does it still make sense? * Can skins.minerva.scripts.top and skins.minerva.scripts be merged after recent RL changes? Is there any advantage to having them separate? * On what pages does the script url differ (e.g. where do we load different JavaScript based on context.. do we only load toggling code on main namespace - if so what disadvantage does that have on client side caching/load time of subsequent page loads? Outcome: T167713 = Questions to answer: * Which modules have side effects (e.g. when loaded make changes to the current page) * Which modules are used by 2 or more features? * What are the advantages to merging modules? * What are the advantages of deferring the loading of code? * What do we load on page load? * What code do we defer the loading of? * Should modules define features or components* How we bundle defer code? * What code is used outside MobileFrontend? Is there justification for sharing it via its own ResourceLoader module?