I don't see many advantages between the sub-module approach and just leaving it in MobileFrontend and have Gather depend passively on a part of MobileFrontend. I mean, the isolation can make us think that they are decoupled but in reality they will still be highly coupled, and we'll need to be as careful.
It may help differentiate where Gather actually depends on MF and where it depends on this base library, which could be useful to identify and remove MF dependencies. Besides that, I don't see much else.
Jon could you please elaborate on the advantages please?On Mon, Apr 13, 2015 at 9:44 PM, Jon Robson <jrobson@wikimedia.org> wrote:No. Explicitly not. This would just be folding our code out into a sub module. The point is to remove dependencies! :)
We dismantled it because code for templating when into core.
On 13 Apr 2015 12:41 pm, "Bahodir Mansurov" <bmansurov@wikimedia.org> wrote:Essentially, does that mean we want to re-create Mantle? If so, we should consider the reasons why we dismantled it.
> On Apr 13, 2015, at 3:10 PM, Jon Robson <jrobson@wikimedia.org> wrote:
>
> I did a quick spike [1] to work out how Gather could stop depending on
> MobileFrontend.
>
> Essentially problems come into 2 categories:
>
> 1) Finding a place for Gather in the desktop skin and addressing
> styling issues in desktop skins (I am working on these and don't see
> any major blockers here).
> I think to fix this we simply need to provide Gather as a desktop beta feature.
> This is tracked here: https://phabricator.wikimedia.org/T95227 and I
> see no issues with doing this.
>
> 2) frontend code standardisation
> The main problem with the hard dependency is that MobileFrontend uses
> a library that was built around the same time as OOJSUI. Migrating
> MobileFrontend to use OOJSUI is a big task and although has happened
> somewhat (the codebase now uses OOJS for class inheritance) it is by
> no means complete.
>
> Gather current depends on a variety of MobileFrontend modules which
> mainly include: API, overlay, user and user setting code, EventLogging
> schema code, notifications code. We also have a method
> mw.mobileFrontend.require and mw.mobileFrontend.define for defining
> modules. OOJS ui does this differently writing class names to the OO
> global variable object.
>
> ==The long term fix===
> ... is obviously to migrate all the code to OOJS UI which I believe
> would require the following steps:
> * https://phabricator.wikimedia.org/T88559 which as an end result will
> rewrite overlay code in oojs ui
> * Rewriting mw.util.notify as an oo js ui component and folding the
> mobile toast notification into it. -
> https://phabricator.wikimedia.org/T66565
> * Core should have a way to store user settings in localStorage rather
> than using $.cookie (similar to M.require( 'settings' ) ) - something
> akin to https://phabricator.wikimedia.org/T67008
> * EventLogging Schema.js should be ported to oojs ui and moved into core.
> * We only use user for the getEditCount function - it would be trivial
> to rewrite using mw.user
>
> == the short term fix==
> We could split out the frontend library MobileFrontend uses to allow
> us to share it between Gather and MobileFrontend.
>
> The way I see this working is to merge all the shared generic JS code
> into its own project just like oojs ui and slowly rewrite it there
> till it is pure oo js ui. This would take everything in the
> javascripts/common/ folder except application.js and bundle it into
> one file.
>
> We could include this as a submodule in both projects, both extensions
> conditionally adding a RL module for it when it does not exist.
>
> What do people think about taking this approach on the short term?
>
> [1] https://phabricator.wikimedia.org/T94100
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l