Flow/Front-end meeting

Met 2013-01-21

Doing a front-end
Do API entirely through JSON

Keep track of which parts have been requested.

Some of it will use the PHP mw.ui and the OO-UI approach.

Data model
A tree of of objects that emit events.

Build out a UI that listens for these events, and add widgets for them. A data tree and a widget tree that are linked by events.

Unlike jQuery which focuses on sticking stuff in the DOM, OOjs UI doesn't trust the DOM (except for input events).

Benefits
You never root around in jQuery to find things, you always know what you're working with.

Replace items with

Plug-ins to change things are a lot of easier, the events become an implicit API on the client.

Performance: don't have to normalize from the DOM.

You can reuse the higher-level events to manipulate your data model to do cool things.

Widgets
A widget has jQuery element, and contains nested widgets.

Flow would probably have to build its own.

Server-side
Timo: Basic button looks the same, but is enhanced by JavaScript?

Trevor: if no-JS and JS are allowed to diverge, then it's easier to let the JS version do really cool things, like real-time.

Differences
Flow doesn't need VE's single event controller to support undo of anything.

Flow objects

Object rendering, the object knows to render itself.

Flow's approach
Already moving this way with Matthias JS patch.

Flow items already render themselves. So why not always get the HTML of a post from the server?

Example: progressive loading of Flow board: you see HTML of first 10 topics, but only titles of next 20. Need a data model to keep track of what data we have.

View of a post linked to a model.