Model-driven Views: Design

Synopsis

This document lays out the design for Model-driven Views (MDV): A proposal for extending HTML and the DOM APIs to support a sensible separation between the UI (DOM) of a document or application and its underlying data (model). Updates to the model are reflected in the DOM and user input into the DOM is immediately assigned to the model.

<div id="example">
Goals:
<ul>
<template iterate>
  <li>{{ goal }}</li>
</template>
</ul>
</div>
...
<script>
document.getElementById('example').model = [
  {goal: 'Fast'},
  {goal: 'Safe'},
  {goal: 'Simple'},
  {goal: 'Stable'}
];
</script>

Note: Extra whitespace/formatting is added in the output part of code samples for clarity's sake. Template instances in the design and prototype do not add extra whitespace.

<div id="example">
Goals:
<ul>
<template iterate></template>
  <li>Fast</li>
  <!--template-instance-->
  <li>Safe</li>
  <!--template-instance-->
  <li>Simple</li>
  <!--template-instance-->
  <li>Stable</li>
  <!--template-instance-->
</ul>
</div>

Audience

The intended audience of this document is browser implementors who wish to understand the work done so far by Google. This document (along with the prototype that implements most of the design described) is intended as a starting point for a discussion about how to best solve the broad motivations of this effort.

The design is not complete. Following each section is a list of open issues. Separately, aspects of the design which are currently sub-optimal are called out as needing more attention.

Design Considerations

  1. Fast. DOM updates should be at least as fast as (and ideally faster than) use of innerHTML, node.cloneNode(true) and direct use of the DOM APIs.
  2. Safe. MDV should neither create new attack surfaces nor encourage practices in applications which do.
  3. Simple. Dramatically reduce the amount of code required to wire up application logic and the DOM.
  4. Stable. Transient state of DOM structures such as event handlers, user input and application-specific use of node properties should never be destroyed as a side effect of MDV's operations.

Design Overview

The overall design for MDV has five main components

  1. Observable data mutations creates a mechanism for the DOM to observe changes to application data so that it can react appropriately.
  2. Model ownership locates the model data which the DOM and application script share within the DOM itself.
  3. Bindings allows individual values of DOM nodes to be dependent on one or more model values and for user input values to be assigned to model values.
  4. Templating creates a high-level construct for declaring sections of DOM which can be instantiated dependent on the presence and quantity of underlying model data.
  5. Asynchronous Processing Model specifies the behavior of bindings and templates such that all DOM updates required after a sequence model mutations can be deferred until the current script event exits. Further, the required work to the DOM can be safely processed without risk of running application script while it is under way.