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.

 Remaining plan

1. 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.
2. Add the ReferencesController class, which has one method, #onReferenceClick, which is invoked when the user clicks a reference, and maintains the contains the key state of the system: whether the references drawer is already open; whether a reference description is being fetched from the API (in the case of the lazily loaded references feature).

 Background

The conversation started during the code review of 278081 and is – roughly – as follows:

@phuedx:

[…] 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.

@Jdlrobson:

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

Thoughts?

@bmansurov:

We usually pass gateway, api and such to the View. So this looks more consistent to me.

@Jdlrobson:

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?

@bmansurov:

Yes that sounds good.

Previously....

We split references.js out 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