Currently, this task captures the conversation around the refactoring of the [`mobile.references`](https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/tree/master/resources/mobile.references) module.
# Split references.js out into:
** the `CiteReferencesGateway` and `MobileViewReferencesGateway` classes, which are responsible for fetching references data from some external service. All gateway class have a `#getReferencesByRevID` method; and
** the ReferencesGatewayFactory class, which constructs an instance of the appropriate gateway class based on some config, e.g. `wgMFLazyLoadReferences.useMobileViewApi`
# The `ReferencesDrawer` class is reduced to a simple view by extracting the logic from the `#showNestedReference` method, which tracks whether the reference drawer is already open, into the `ReferencesController#onReferenceClick` method.
# Add the `ReferencesController` class, which has one method, `#onReferenceClick`, which is invoked when the user clicks a reference, given the current state of the system – whether or not the references drawer is already open.
The conversation started during the code review of (https://gerrit.wikimedia.org/r/#/c/278081/) and is – roughly – as follows:
> […] I'm not in favour of this addition to the ReferencesDrawer view class. Previously, the distinction between the controlling part of the references machinery (the code in the setup file) and the corresponding view was adequately separated. In this change, the ReferencesDrawer is now concerned with fetching references for reference links as well as rendering them. This function should actually be in the setup file.
> One way of achieving this would be to trigger an event representing a reference click so that it can be handled elsewhere.
> It feels like this should be inside the ReferenceDrawer so I think in a follow up we should explore moving a lot of this logic into the ReferencesDrawer itself.
> Code I think we should move into ReferenceDrawer:
> * `getReferenceData`
> * `getReference`
> * `mw.trackSubscribe`
> We usually pass gateway, api and such to the View. So this looks more consistent to me.
> Okay.. so if we have a ReferencesGateway, we'd pass it to ReferenceDrawer, this would mean this code could be done inside ReferenceDrawer using the ReferencesGateway.
> Does that sound right?
> Yes that sounds good.