Page MenuHomePhabricator

MFA: [Spike, 8hrs] Views: You Gotta Keep 'em Separated
Closed, ResolvedPublic0 Estimated Story Points


This is a spike to identify some of the separation concerns and easily accomplished gains in splitting responsibilities among MobileFrontend's views. The outcomes of this task are more tasks.

  • Visit each Overlay.
    • Does it manage low-level view concern stuff like adding an item to a list or digging deep into a button and binding a listener? Thoroughly review each Overlay module and try to task out a plan for moving just the View code into a new a View-concerns-only file using the existing View patterns. For example, CategoryOverlay's View logic could be moved to CategoryOverlayView that subclasses View (like all other Views do) and then CategoryOverlay just composes it like it composes a gateway.
    • Does the overlay have its own private gateway but then marshal the data to new models? Make a task to move the marshaling to the gateway.
  • Visit each View. Does it have a gateway? Does it do other WEIRD STUFF that doesn't have much to do with views like changing window.location? Make a task to move it somewhere else.

The focus of this task is to document View refactoring that is achievable in the very near term. Don't worry about anything else except separting the Views out so they can be considered and refactored independently of other code. For example, if FooView.js
changed from using Hogan.js to Preact, hopefully after the separation very little outside the View itself would need to change.


  • Patches shouldn't be needed, but if they help illustrate your write up go for it! Remember to use the WIP tag and mark as abandoned.
  • Write up - ideally on in your user namespace.
  • Identify common problems/code patterns. Include a table in your write up to give a clear idea of which views have which problems
  • Prepare and arrange to discuss it in super happy dev time

Sign off steps

  • Reopen/update/close T205592 as necessary. (seems relevant to the newly opened epic. Unstalled and updated)
  • Update and un-stall T207770 as necessary with learnings. (no changes but can happen after we've targeted View's)
  • Update and un-stall T206335 with any applicable information (no changes but can happen after we've targeted View's)
  • Update T209647 with newly acquired information (declined)

Event Timeline

Restricted Application changed the subtype of this task from "Deadline" to "Task". · View Herald TranscriptOct 2 2018, 9:01 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@ovasileva, @Jdlrobson, this is a spike independent of the Webpack work that would greatly support identifying upcoming and very important work for the investment project. I recommend bringing it onto the board soon!

Jdlrobson renamed this task from Views: You Gotta Keep 'em Separated to [Spike, 8hrs] Views: You Gotta Keep 'em Separated.Oct 3 2018, 8:31 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from Needs Prioritization to Upcoming on the Web-Team-Backlog board.

Does the above look good Stephen? I made a few edits of my own.

@Jdlrobson, I think so. I'm mostly concerned with identifying specific concrete tasks to work on immediately. I personally don't care how that happens or even if it's a thorough effort or not. It's my understanding that we all agree that view logic must be separated from everything else so that when we work / test / refactor views in the future, we only touch view code.

@ovasileva hoping we can talk about this in prioritisation tomorrow. This is becoming important for understanding how the team is going to handle refactoring the rest of the codebase.

Jdlrobson set the point value for this task to 0.Nov 7 2018, 5:25 PM

We chatted about this today. I recommend someone other than @Niedzielski or I work on this.

Jdlrobson renamed this task from [Spike, 8hrs] Views: You Gotta Keep 'em Separated to MFA: [Spike, 8hrs] Views: You Gotta Keep 'em Separated.Nov 15 2018, 6:58 PM

I've been a bit too distracted this week and should be truthful about that. I've spent maybe 4 distracted hours on this and it's been hard to identify very specific and well contained tasks. This spike for me morphed into making a document about all MobileFrontend's Views (components) and all the ideal components it should contain:

This document is incomplete, but hopefully provides a way for us to understand our component hierarchy and their dependencies.

On hindsight I should have probably scoped this to Overlay's rather than attempted all Views.

On a general note, when I look at these components, the main pattern I see is X extends Y but is actually Y with A, B, C components inside it (but from the templates/class that is not obvious) so the google doc helps provide some assistance here.
Without a clear plan for T209647 it's hard to make concrete recommendations (tasks) to change that pattern.

I will return to this (if incomplete) when I get back, but please feel free to pick off where I left of or take a different approach to this spike. I've given you all editing rights.

I think we can benefit from separating responsibilities like this example for PageIssuesOverlay:

I'm looking at other View's to determine whether we can do similar things.
The benefit of this is that it will at least separate Overlay code from Overlay contents...

Okay, so please consider a living document that's unfinished. I've easily used up my timebox so I'm not planning to add to it anymore. I think the work we can do here is easily several epics, but the first one I would like to focus on is a task with the title "[EPIC] Nothing should extend the Overlay class" (a subtask of T195482) - the milestone and cover CategoryAddOverlay, CategoryOverlay, AbuseFilterOverlay, EditorOverlayBase, LanguageOverlay, ImageOverlay, NotificationsFilterOverlay, TalkOverlay, TalkSectionAddOverlay, TalkSectionOverlay, LoadingOverlay, SearchOverlay and PageIssuesOverlay. We'll know when we're done when we can grep "extends Overlay" and see no results (if this doesn't make sense, continue reading until the end and read this paragraph again!).

After spending time looking at how things are wired up and playing with two of the most simple examples of Overlay's, I would recommend we replace all these classes with factory methods that return an Overlay composed of several children. View's will still not be fully separated (rather they will be simplified). For instance TalkSectionOverlay would become talkSectionOverlay that returns an Overlay with a child TalkWidget and PageGateway / EditorGateway usage will be moved to the TalkWidget. This is beneficial as it throws away some redundancy in our templates, removes the need for many of our template partials and removes a level of inheritance.

We will replace Overlay's with sub components that extend the View class and add them as children in the factory function. Here's some examples with the LoadingOverlay and PageIssuesOverlay:

Once Stephen has made it possible for us to pass events as properties (in T210870) I think we will have what we need to apply that to all of the other classes. To start with I'd suggest focusing on the TalkOverlay's given it links quite nicely to AMC. This will also allow us to remove the LoadingOverlay (which will help T209708 but more on that later)

Please ask any questions, if I have no objections, I'll setup the task for epic and the Talk's and scheduled a conversation in super happy dev time when we get back. If we find this doesn't work out we'll go back to the drawing board and come up with another plan.

I have opened up T212465 as the next logical step. Please take a read through and let me know if anything is not clear. We'll talk about that in the next super happy dev time. Sound good?

We will talk about T212465 in next-super-happy-dev time. I've added it to agenda.