Page MenuHomePhabricator

[EPIC] None of our View's should exhibit 2 levels of inheritance
Open, MediumPublic

Description

Progress is measured here: mediawiki.org

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.

How?

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.

Outcomes

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
  • We have documented a best practice for how to make new overlay's / components going forward

When is it done?

This EPIC can be resolved when the following classes either do not exist (replaced with factory functions or removed)

  1. Documentation on how to make View's has been written
  2. The following query should return 0 results in Minerva and MobileFrontend.

ag "extends Overlay"
ag "extends Drawer"
ag "extends Icon"
ag "extends PageList"

Icons

Drawers and Panels

  • BetaOptinPanel extends Panel -> extends View T217298
  • BlockMessage extends Drawer -> is Drawer
  • Drawer extends Panel -> is View
  • CtaDrawer extends Drawer -> is Drawer (red links + watchstar when anon!)
  • ReferencesDrawer extends Drawer -> is Drawer (T217295)

Categories

MediaViewer

  • ImageOverlay extends Overlay -> is Overlay (T216198)

Languages

  • LanguageOverlay extends Overlay -> is Overlay

Notifications

  • NotificationsFilterOverlay extends Overlay -> is Overlay (T217296)
  • NotificationsOverlay extends Overlay -> is Overlay (T217296)

Page issues

Talk

Page lists

  • SearchOverlay extends Overlay
  • WatchstarPageList extends PageList -> is PageList
  • Nearby extends WatchstarPageList extends PageList (T217814)
  • WatchList extends WatchstarPageList extends PageList -> is PageList

Editor

  • AbuseFilterOverlay extends Overlay -> is Overlay
  • VisualEditorOverlay extends EditorOverlayBase extends Overlay -> is Overlay
  • EditorOverlayBase extends Overlay -> devnull
  • EditorOverlay extends EditorOverlayBase -> is Overlay

Misc

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.

What will code look like in future?

All Overlay's will be Overlay's with widgets inside them

e.g.

var overlay = new Overlay( {
  title: 'Editing Spain article'
} );
overlay.append(
  new EditorSurface()
);

Talk:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/471334/7/src/mobile.talk.overlays/talkOverlay.js

Sign off steps

  • Take a look at T214641 and determine whether the issue has been solved. If not adjust/rewrite

Related Objects

StatusSubtypeAssignedTask
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJdlrobson
OpenNone
OpenNone
ResolvedNone
ResolvedJdlrobson
ResolvedNone
Resolved Niedzielski
Resolvedovasileva
DeclinedJdlrobson
ResolvedBUG REPORTJdlrobson
Resolvedphuedx
ResolvedJdlrobson
Resolvedovasileva
DeclinedBUG REPORTJdlrobson
Resolved nray
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedJdlrobson
ResolvedJdlrobson
OpenNone
ResolvedJdlrobson
ResolvedLucas_Werkmeister_WMDE
DuplicateNone
ResolvedLucas_Werkmeister_WMDE
ResolvedMichael
ResolvedMichael
OpenNone
ResolvedAnneT
OpenNone
ResolvedVolker_E
OpenNone
OpenNone
DeclinedNone
OpenNone
OpenNone
OpenNone
StalledNone
StalledNone
ResolvedAnneT
ResolvedStevenSun
DeclinedJdrewniak
Resolvedovasileva
DuplicateBUG REPORTNone
ResolvedCatrope
Resolvedovasileva
ResolvedBUG REPORTEdtadros
ResolvedBUG REPORTovasileva
In ProgressNone
Resolved EUdoh-WMF
Resolvedppelberg
DeclinedBUG REPORTNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Can I ask that an outcome of this epic be well-written documentation about how to author new overlays both within and without the MobileFrontend/MinervaNeue codebases?

Do we want to add any requirements around mfExtend()? I think this is mostly used on Views but it's also used in some surprising places like Skin, ScrollEndEventEmitter, and ReferencesMobileViewGateway. It seems to me that it should only be used for second layer Views.

It might be nice if at least View, and perhaps other inheritance pattern usages, forbid modification via a deep Object.freeze(). This would make it easier to limit and reason about the View API, and prevent unintentional changes to the prototypal hierarchy by child classes.

Do we want to keep mfExtend? Would using ES6 classes make it redundant (and remove the need for the oojs dependency from mobile.startup/ the critical path)

I would love to drop mfExtend!!! I haven't looked into the OO internals so I'm not sure how practical it will be to drop but we could make that our goal and see where we end up?

Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

Change 570196 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Make CategoryAddOverlay use Overlay.make

https://gerrit.wikimedia.org/r/570196

Change 570196 abandoned by Jdlrobson:

[mediawiki/extensions/MobileFrontend@master] Make CategoryAddOverlay use Overlay.make

Reason:

This will be redundant with the approach outlined in https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/ /683441

https://gerrit.wikimedia.org/r/570196

I need to review this epic. The code that is important that remains is the editor code and Special:Watchlist. The talk page code is going to be removed at a future date, as is the search / page lists code .

Jdlrobson lowered the priority of this task from High to Medium.Sep 20 2023, 5:21 PM
Jdlrobson updated the task description. (Show Details)