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.
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@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.
Update: With thanks from Roan IRL I worked out the above problem - it was due to not calling the parent initialize function. I made a few more tweaks and now I have a patch which moves MobileFrontend to using OOJS Class system.
This is a big change that effects our entire stack with a bunch of dependencies and potential merge conflicts. Your help moving towards this would be much appreciated.
The following 5 patches need review in this order:
Move MobileFrontend to using OO.EventEmitter: https://gerrit.wikimedia.org/r/129336
Kill use of super in MobileFrontend: https://gerrit.wikimedia.org/r/159552 https://gerrit.wikimedia.org/r/159555
Switch to using OO.inheritClass: https://gerrit.wikimedia.org/r/159553
After this is done it would be good to sit down and document ways we can make better use of OOJS in mobile.
On Tue, Sep 9, 2014 at 4:47 PM, Jon Robson jrobson@wikimedia.org wrote:
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@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@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
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@wikimedia.org wrote:
On Fri, Sep 12, 2014 at 11:32 AM, Jon Robson jrobson@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@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@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@wikimedia.org wrote:
On Fri, Sep 12, 2014 at 11:32 AM, Jon Robson jrobson@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Update: this is done. Mobile is now using OOJS for its classes and event emitting.
I would appreciate if people could vigorously test things on beta labs. We have already identified two issues [1,2] that seem to have been caused by moving to OO.EventEmitter (I believe the issue is something to do with the fact we cannot scope events) but not investigated them since they are low priority.
Next steps: * I will mail next week about this but we are looking to test drive Trevor's OOUI Template widget. * I'm hoping to take a closer look at modal dialogs built by Flow and Growth and try and find some commonality between mobile's overlays.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=71075 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=71076
On Tue, Sep 16, 2014 at 2:54 PM, Jon Robson jrobson@wikimedia.org wrote:
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@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@wikimedia.org wrote:
On Fri, Sep 12, 2014 at 11:32 AM, Jon Robson jrobson@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l