@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!

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.

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

Okay, so please consider https://docs.google.com/document/d/1pxTYAu6tIIPR-8TpUJ5_qKdumj8P76k3cbVo-WJAuzU/edit?usp=sharing 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:

• LoadingOverlay (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/468187/10/src/mobile.startup/LoadingOverlay.js)
• PageIssuesOverlay (https://gerrit.wikimedia.org/r/475576)

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?

Sounds good to me