When discussing usages of mw.track inside RelatedArticles and whether it should use mw.hook, we came to the conclusion that we didn't need to use either.
The use of the hook/track dates back to now obsolete requirements that related articles rendered differently under different circumstances.
Since this is not the case, we believe this code can be simplified by merging the render and bootstrap code into one single file and module.
We will load all code on page load - it's not worth the complexity and fragmentation of cache to defer load the related articles rendering code given its size and the fact it will be cached after the initial page view.
Given the discussion in T176211, relating to serving unnecessary JavaScript we should
- divide the code into 2 modules - a lightweight ext.relatedArticles.readMore.bootstrap module and a larger ext.relatedArticles.lib
- mw.trackSubscribe( 'ext.relatedArticles.init' inside ext.relatedArticles.readMore should become an init method that is exported by the module
- init should be invoked inside the loadRelatedArticles method of ext.relatedArticles.readMore.bootstrap
Background conversation
See discussion at T143572: Why are we using mw.track in related pages as an event bus?
Much of this is redundant, but explains the initial motivation for this card.
For consistency sake and good usage of the apis (regarding the docs) usages of mw.track (for example in RelatedArticles) that are not analytics related should be changed to use mw.hook instead.
Previous convos
Acceptance criteria
- logReady, logEnabled, init should use mw.hook not mw.track