This begins our refactoring effort and aims to minimise the use of inheritance in MobileFrontend. We will reduce components to classes that extend the View class to minimise confusion in navigating through files to understand how the inheritance change impacts our component.
Per T206036#4832740 (MFA: [Spike, 8hrs] Views: You Gotta Keep 'em Separated) and similar discussions in T209647 our main focus will be the Overlay's. We will limit efforts to separating the content of overlays from the overlay itself.
We can replace many of our classes with factory functions that create Overlays and append child components via jQuery.
The LoadingOverlay probably provides the most simple to explain example: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/468187/14/src/mobile.startup/loadingOverlay.js
We will look to generate many of our View's in this way, resorting to using existing components with different options (think React-like props). Where needed, we will add functionality/flexibility to View and Overlay classes to generalise different component needs - for example in the LoadingOverlay example a will described property `noHeader` was added.
The outcomes of this epic will be:
- More granularity in our components and more reuse
- The DRYing up of many template and template partials
- Easier to read code.
- The ability to remove the LoadingOverlay - instead, Overlay factories will be able to limit the spinner/async loader indicator to the Overlay content
= When is it done?
This EPIC can be resolved when the following classes either do not exist (replaced with factory functions or removed)
The following query should return 0 results in Minerva and MobileFrontend.
> ag "extends Overlay"
> ag "extends Drawer"
> ag "extends Icon"
> ag "extends PageList"
 CategoryOverlay (https://gerrit.wikimedia.org/r/469145)
[x] LoadingOverlay (https://gerrit.wikimedia.org/r/468187)
 PageIssuesOverlay. (https://gerrit.wikimedia.org/r/475576)
 TalkOverlay (https://gerrit.wikimedia.org/r/469536)
= What happens after this epic?
We'll review the newly created components and with a spike evaluate how we can break them down further.
As part of this we may decide to target one specific overlay and refactor until completion to show/prove to ourselves this will result in more manageable and testable code.
= Do we write new tests?
This will be decided by the team as and when we work on this. We'll talk about our commitment to code coverage and how it will change during this refactor.