Update: Roan's patch got merged but Max identified an issue with it in MobileFrontend which is stopping us switching over to use it in MobileFrontend [1] It seems to be related to an event that we use called 'progress' that we use in our api handler. You can replicate it by trying to do a wikitext edit in the stable mode of the mobile site with the above patch. Uncaught TypeError: Cannot use 'in' operator to search for 'progress' in undefined load.php?debug=false&lang=en&modules=ext.mantle%7Cext.mantle.hogan%2Cmodules%2Coo%2Ctemplates%7Cjqu…:68oo.EventEmitter.emit load.php?debug=false&lang=en&modules=ext.mantle%7Cext.mantle.hogan%2Cmodules%2Coo%2Ctemplates%7Cjqu…:68(anonymous function) Not sure if this is an issue with OOJS or the patch Roan made for us. Any ideas VE guys? [1] https://gerrit.wikimedia.org/r/#/c/129336/ On Fri, Aug 22, 2014 at 11:36 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: > Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside > the mobile and Flow projects. > > The following 3 patches kicks off moving MobileFrontend's class model > towards that of oojs - many thanks for Roan for doing most of the > legwork :-): > https://gerrit.wikimedia.org/r/155593 > https://gerrit.wikimedia.org/r/155589 > https://gerrit.wikimedia.org/r/129336 > > On the long term we'd look to swap out the Class.js and > eventemitter.js files in MobileFrontend for oojs, but this is going to > be tricky and require some care, possibly mixing both oojs and > MobileFrontend's class code in the repository at the same time. e.g. > increasing JavaScript on the short term, but reducing it on the > longterm. The MobileFrontend core development team will need to work > out how best to manage this transition. > > Since Flow is very DOM-focused, as opposed to many smaller JavaScript > modules with element management per the currently-accepted use of > OOjs, it is unclear how we may go about integrating with OOjs fully. > However, some potential use cases have been identified as candidates > for implementing OOjs on an interim basis, primarily by abstracting > some current FlowBoardComponent workflows, such as those which handle > (re-)rendering of existing and new content fetched from the API.

On Fri, Sep 12, 2014 at 11:32 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: Are you thinking of retooling existing features/infrastructure to use it first or making this a requirement for new features? This sounds like a good discussion to have during the quarterly planning but I certainly think we shouldn't wait that long to do it. --tomasz _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Update: Since these changes touch every single bit of mobile's code and might have scary unforeseen consequences we are going to review/merge these after this weeks deployment. I've scheduled a pair programming session with Kaldari on Friday to do this. On Fri, Sep 12, 2014 at 3:14 PM, Trevor Parscal <tparscal(a)wikimedia.org> wrote: > Jon, this is really awesome. I'm excited to be sharing more code. > > I'll be taking a look at these patches with Roan today. > > - Trevor > > On Fri, Sep 12, 2014 at 11:43 AM, Tomasz Finc <tfinc(a)wikimedia.org> wrote: >> >> On Fri, Sep 12, 2014 at 11:32 AM, Jon Robson <jrobson(a)wikimedia.org> >> wrote: >> > After this is done it would be good to sit down and document ways we >> > can make better use of OOJS in mobile. >> >> Are you thinking of retooling existing features/infrastructure to use >> it first or making this a requirement for new features? >> >> This sounds like a good discussion to have during the quarterly >> planning but I certainly think we shouldn't wait that long to do it. >> >> --tomasz >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > >