Change Details

See discussion at {T143572} 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. * Where [an event is triggered when scrolling](https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/83d06e997d70aa7ede772df7efe8f37d429bc361/resources/ext.relatedArticles.readMore.bootstrap/index.js#L64) * Where we [initialize the lazily loaded related articles](https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/83d06e997d70aa7ede772df7efe8f37d429bc361/resources/ext.relatedArticles.readMore/index.js#L41) ==Previous convos== >>! In T143572#2585857, @phuedx wrote: > IIRC I chose to use `mw.track` and `mw.trackSubscribe` in this way because I wanted to: > > # keep the data source and the renderer (specific to Vector, Minerva, etc.) cleanly separated; > # avoid writing code like `ext.relatedArticles.render = /* ... */`; and > # ensure that the event was received by the listener, regardless of when the listener was loaded >>! In T143572#2590262, @Jhernandez wrote: > @phuedx I agree with why you used it, but I'm not sure `mw.track` is the best option given that the docs state it is for analytics purposes. > > I believe there's already a global event bus in the form of [`mw.hook`](https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook) that would probably be more appropiate: > >>>! //mw.hook// >> This framework helps streamlining the timing of when these other code paths fire their plugins (instead of using document-ready, which can and should be limited to firing only once). > > VS > >>>! //mw.track// >> Track an analytic event. >> >>This method provides a generic means for MediaWiki JavaScript code to capture state information for analysis. > > At the end they are both as useful for this specific use case, I just wondered about the approach because of what the docs say.

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. == Background == See discussion at {T143572} 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. * Where [an event is triggered when scrolling](https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/83d06e997d70aa7ede772df7efe8f37d429bc361/resources/ext.relatedArticles.readMore.bootstrap/index.js#L64) * Where we [initialize the lazily loaded related articles](https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/83d06e997d70aa7ede772df7efe8f37d429bc361/resources/ext.relatedArticles.readMore/index.js#L41) ==Previous convos== >>! In T143572#2585857, @phuedx wrote: > IIRC I chose to use `mw.track` and `mw.trackSubscribe` in this way because I wanted to: > > # keep the data source and the renderer (specific to Vector, Minerva, etc.) cleanly separated; > # avoid writing code like `ext.relatedArticles.render = /* ... */`; and > # ensure that the event was received by the listener, regardless of when the listener was loaded >>! In T143572#2590262, @Jhernandez wrote: > @phuedx I agree with why you used it, but I'm not sure `mw.track` is the best option given that the docs state it is for analytics purposes. > > I believe there's already a global event bus in the form of [`mw.hook`](https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook) that would probably be more appropiate: > >>>! //mw.hook// >> This framework helps streamlining the timing of when these other code paths fire their plugins (instead of using document-ready, which can and should be limited to firing only once). > > VS > >>>! //mw.track// >> Track an analytic event. >> >>This method provides a generic means for MediaWiki JavaScript code to capture state information for analysis. > > At the end they are both as useful for this specific use case, I just wondered about the approach because of what the docs say. = Acceptance criteria [] logReady, logEnabled, init should use mw.hook not mw.track

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. == Background == See discussion at {T143572} 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. * Where [an event is triggered when scrolling](https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/83d06e997d70aa7ede772df7efe8f37d429bc361/resources/ext.relatedArticles.readMore.bootstrap/index.js#L64) * Where we [initialize the lazily loaded related articles](https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/83d06e997d70aa7ede772df7efe8f37d429bc361/resources/ext.relatedArticles.readMore/index.js#L41) ==Previous convos== >>! In T143572#2585857, @phuedx wrote: > IIRC I chose to use `mw.track` and `mw.trackSubscribe` in this way because I wanted to: > > # keep the data source and the renderer (specific to Vector, Minerva, etc.) cleanly separated; > # avoid writing code like `ext.relatedArticles.render = /* ... */`; and > # ensure that the event was received by the listener, regardless of when the listener was loaded >>! In T143572#2590262, @Jhernandez wrote: > @phuedx I agree with why you used it, but I'm not sure `mw.track` is the best option given that the docs state it is for analytics purposes. > > I believe there's already a global event bus in the form of [`mw.hook`](https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook) that would probably be more appropiate: > >>>! //mw.hook// >> This framework helps streamlining the timing of when these other code paths fire their plugins (instead of using document-ready, which can and should be limited to firing only once). > > VS > >>>! //mw.track// >> Track an analytic event. >> >>This method provides a generic means for MediaWiki JavaScript code to capture state information for analysis. > > At the end they are both as useful for this specific use case, I just wondered about the approach because of what the docs say. = Acceptance criteria [] logReady, logEnabled, init should use mw.hook not mw.track