Flow/Front-end meeting

Met 2013-01-21 with Trevor, Timo, JamesF

Trevor talks

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 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.

• Bulleted list item

Differences

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

VE has few instances of many different objects on a content surface; Flow has many instances of Flow objects in HTML.

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.

Sketch out design

Data model

Create generic JS object.

• Mix in event emitter.
• Build aggregate data object
• VE has the idea of branch object where you can splice in children
• OOdmBaseModel,
• Placeholder of placeholders
  • VE uses sparse arrays to represent things

addPost would bubble up to the topic, and the topic would do things like increase the NN comments counter and names of people in the conversation.

Likewise

• add, remove, changePost events.
• moderation actions. These all generate server revisions.
  • server responds

Currently:

• server supplies URLs for allowable actions
• only generate UI for allowable actions

Trevor: you click reply, make your post, it creates a placeholder reply in your data model, then the server replaces it.

• Could store "drafts" of posts in the data model.
• Store drafts in local storage.

OOjs UI

Data model above is separately.

Using OOjs UI comes later.

Maybe use factory state.

Next steps

Monday hackathon, immediately before our Monday deploy.

• build data model
  • somehow output stuff from this
  • Matthias work taking us down the right path, we hope.

• Set up a long-lived branch.