Page MenuHomePhabricator

Extract MobileFrontend UI components to an external well documented library
Closed, DeclinedPublic

Description

Blocked on: T155802

Why

MobileFrontend has 1700 lines of asset configuration and an extensive library of UI components that is mixed with the business logic of the frontend application.

By extracting a library we can focus on clear interfaces and abstract away most of the FE configuration to make MobileFrontend more maintainable.

Original request

  • Extract core/foundational UI components, document the hell out of them, providing examples of how to use them to build new features, and place them way, way, WAY outside of the standard MobileFrontend hierarchy
    • Since Joaquin introduced me to it, I always think of Redux when I think of the outstanding documentation

POC

Component migration list

ComponentSource url(s)AsigneeStatus
Cardsextension/Cards@phuedxIn progress
Viewmobile.view/View
Overlaymobile.overlays/Overlay
............

Related Objects

StatusSubtypeAssignedTask
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJdlrobson
DeclinedNone
ResolvedJdlrobson
Resolvedphuedx
ResolvedJdlrobson
ResolvedJdlrobson
DuplicateSpikeNone
ResolvedJdrewniak
DeclinedNone
ResolvedJdlrobson
DeclinedNone
ResolvedJhernandez
ResolvedJdrewniak
Resolvedpmiazga
ResolvedJdrewniak
ResolvedJdlrobson
ResolvedJdrewniak

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 31 2016, 3:55 PM
Jhernandez updated the task description. (Show Details)Aug 31 2016, 3:56 PM
Jhernandez added a subscriber: Jdlrobson.

@phuedx @Jdlrobson Would creating a npm library kind of like oojs did make sense?

Yes. I thought I raised a bug for this a while ago.
I'd like to see at least all the basic components in mobile.startup, mobile.oo, mobile.overlays and mobile.view pulled into as separate library that depends on OOjs.
We can give it a random name e.g. jigsaw.js and then I'd then like to see this library export all components like so:

module.exports = {
Overlay: Overlay,
View: View,
...
};

We'd need to drop the use of M.define in those libraries and work out how to load templates without introducing the mw.template.get dependency which imo is a good step in the right direction.

We should be wary of increased JS payload in doing this.

Jhernandez updated the task description. (Show Details)Oct 7 2016, 8:51 AM
phuedx updated the task description. (Show Details)Oct 7 2016, 10:25 AM

How can I help with this initiative?

@Jdlrobson I've added you to mfui, some help with the prs review would be great.

We can chat later about the repo and figure out next steps.

Jhernandez added a subscriber: bmansurov.

@bmansurov from your email (sorry I didn't answer before), this is an Epic I want us to work on. I've added that tag hoping is the right one. Let me know.

Jdlrobson changed the task status from Open to Stalled.May 2 2017, 10:45 PM
Jdlrobson triaged this task as Low priority.
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from Later to Blocked on the Readers-Web-Backlog (Tracking) board.
Jdlrobson moved this task from Inbox to Tracking on the User-Jdlrobson board.Sep 27 2017, 8:58 PM
nray awarded a token.Oct 29 2019, 5:33 PM
Jdlrobson closed this task as Declined.Jan 17 2020, 11:43 PM

At this point if we want we can publish MobileFrontend's library to npm, but I'm not sure if there are any benefits to doing so.

Given I can't see anything actionable here, I'm going to decline this bug saying that enough has changed.