Heads up that Shahyar from the Flow team met up with Juliusz and I to discuss better code sharing and thus easier integration betwen Flow and MobileFrontend. It seems we are doing various things in a similar fashion and there is an opportunity to share code.

You can see Shahyar's notes below but the main areas that could do with immediate consolidation are as follows:

* Both use client side templates but with different template libraries. MobileFrontend has a method of serving these via ResourceLoader. We recommended that we consolidate this code asap and aim to push it into core, rather than have the situation where we are both using our own code. We should make this template agnostic to fit in with the ongoing RFC around client side templates. I cut a story card to try and get this on MobileFrontend's radar - https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1800 * Flow uses jquery microsize to auto expand a textarea when typing, mobile has its own lightweight library to do this. * Both Flow and MobileFrontend use a lightweight library to generate user friendly last modified timestamps ( e.g. 3 days ago etc) - this is much smaller than moment.js in core * Both extensions use Class inheritance JavaScript model.

---------- Forwarded message ---------- From: Shahyar Ghobadpour sghobadpour@wikimedia.org Date: Tue, Mar 25, 2014 at 2:34 PM Subject: Mobile & Core Features front-end meetup technical notes To: "Editor engagement list for the core E2 development team." e2@lists.wikimedia.org Cc: Juliusz Gonera jgonera@wikimedia.org, Jon Robson jrobson@wikimedia.org, Tomasz Finc tfinc@wikimedia.org

Core Features met up with the front-end guys from Mobile, and we, in Maryana's words, creeped on each others' code. This gave us a lot of insight into how our teams have been doing things (spoiler alert: it's very similar).

Here are my notes, from Flow's perspective on things:

Classes

Can extend objects Call parents with .super Notable classes:

EventEmitter

Binds events to objects, but is in fact just a wrapper for jQuery.Events

Overlay M

Uses M.require to grab a constructor/class

Not big, just basically to make sure that the loading order is correct and all requested modules actually exist New ones added via M.define

Templates

Hogan methods:

preRender postRender

Most useful; adds logic to templates after the fact Currently, they use this to find elements and bind (events) directly to them

mw.template implements template compiling, getting, adding

mw.template.add is called by resourceloader Currently uses Hogan only, but could easily be changed to use Handlebars (could even just overload mw.template.compile)

History State Management

Currently only implements hash change event

Android 2.3 and Android 4.0 do not correctly (how?) support history API for adding more URLs to the history

Currently still in flux due to various issues

Would be worth combining efforts to make a better one

API

mw.api sucks, they wrote their own Each API is subclassed

eg. editorApi implements its own special methods on top of Api

CSS

Has separate responsive styles for tablet and for phone

In individual files and loaded when needed, so as to not slow down the base CSS with too many media queries

Might change; they may end up getting concatenated later on for simplicity

At 768px adjustment begins for media queries (to be standardized between Mobile and Flow)

Misc

Custom micro.autosize.js

Automatically resizes textareas as you type Only 600 bytes unminified

--Shahyar