This document discusses synchronizing application state across devices using virtual DOM trees. It introduces liquid applications which allow transferring an application between devices. The state of an application includes both JavaScript variables and the DOM tree. Modern frameworks use a virtual DOM to represent the real DOM tree. The proof of concept presented serializes the initial DOM state and uses a virtual DOM library to generate operations to synchronize the current state. It provides APIs for developers to minimize implementation needs and register dynamic functions to transfer between devices. Examples of a todo list application demonstrate the concepts.

1. © Gofore Oy 2016 •
Synchronizing Application State
Using Virtual DOM Trees
Jari-Pekka Voutilainen,
Tommi Mikkonen and
Kari Systä
Jari-Pekka Voutilainen

2. Me
• PHD student at Tampere University of Technology
• Researched Browser applications since 2011
• Currently working at Gofore Ltd.
• Finnish software consultation company
• @zharktas in twitter
• Jari.Voutilainen@iki.fi
Jari-Pekka Voutilainen 2

3. Agenda
• Background
• Liquid applications
• Browser application state
• Virtual DOM
• Serializing browser state
• Demos
Jari-Pekka Voutilainen 3

4. Background
• Multiple devices
• Applications need to be installed multiple times
• Applications might be in different states
• Applications require large scale backend for storing state
• Transferring application between devices is not currently feasible.
Jari-Pekka Voutilainen 4

5. Liquid Applications
• Defined as applications that can flow from device to device.
• Three subsystems were identified:
• User interface
• Persistent data and content
• State of the application
Jari-Pekka Voutilainen 5

6. Liquid applications
• This study focuses on the state of the applications.
• Multiple options for migrating browser application state:
• Complete memory space of the browser
• Pre-defined set of variables
• Determining relevant state from the application
Jari-Pekka Voutilainen 6

7. Liquid Application Framework
• The goal is to make developing liquid applications simple.
• Developers had to implement specific APIs for application transfer.
• Application should not be designed to be liquid.
• Basis should be in existing browser implementations.
• Liquid applications do not need to be installed everywhere, therefore they
should not require custom browser.
• Application should be device agnostic.
Jari-Pekka Voutilainen 7

8. Browser application state
• Our previous studies:
• Largely focused on JavaScript variables
• Lively3D had pre-defined variables which were serialized
• Backend-as-a-Service projects which stored variables to cloud database
• HTML5 Mobile Agents allowed user defined variables which were serialized
with the agent.
Jari-Pekka Voutilainen 8

9. Browser application state
• JavaScript variables are not the only state in applications that is relevant.
• Most modern web applications store some of the state to the DOM tree.
• Dynamically created elements, styles and so on..
• Most modern JavaScript frameworks do this behind the scenes.
Jari-Pekka Voutilainen 9

10. Virtual DOM
• Popularized by React.js.
• Novel technology, multiple implementations.
• Abstract version of the DOM tree.
• Usually consists of the following algorithms:
• Creation
• Manipulation
• Comparison
• Applying to DOM tree
Jari-Pekka Voutilainen 10

11. Proof of Concept
• Our proof of concept focuses on the state synchronization.
• Requires minimal implementation from the developer.
• Main contribution is in the browser side
• Server side is minimal implementation to enable migration
• Could be implemented numerous ways, currently using WebSockets.
Jari-Pekka Voutilainen 11

12. Proof of concept
• Our Proof of Concept is based on the initial state of the application.
• Virtualized from DOM tree after the application has loaded.
• Can be used as a comparison point to whatever state the DOM tree has.
• Virtual DOM library used in the PoC, provides comparison algorithm which
creates a set of operations needed to execute for DOM tree to change from
a to b.
Jari-Pekka Voutilainen 12

13. State transfer
• Our PoC creates required set of operations to migrate from initial state to the
current state.
• Can not be migrated as such since JavaScript object prototypes are not
serialized.
• Some of the prototype information is stored with the object so that the
prototypes can be recreated in the next browser.
• Receiving browser applies the operations to its initial state and applies this to
the actual DOM.
• Application DOM is migrated from browser to browser.
Jari-Pekka Voutilainen 13

14. Issues
• Only data present in the DOM is migrated.
• Functions bound to the DOM elements are actually in JavaScript namespace
• Bindings are lost when DOM is migrated.
• To compensate PoC has means for developers to register functions and how
they are bound in DOM
• These are serialized and rebound after migration.
Jari-Pekka Voutilainen 14

15. Demos
• Example application: Todo list
• User can add items, mark them done and remove them
• All of the state of application is stored to the DOM for the sake of demo
• TODO app
Jari-Pekka Voutilainen 15

16. Minimal implementation
• To enable state migration, developer needs minimal implementation.
Jari-Pekka Voutilainen 16
State transfer
var Liquid = require(‘@zharktas/liquid.js');
var liquid = new Liquid();

17. Binding dynamic functions
• To transfer dynamic functions, developer needs to register the functions and
note them in the DOM
Jari-Pekka Voutilainen 17
Bound functions
var checkbox = document.createElement('input');
checkbox.addEventListener('click', someFunction);
checkbox.setAttribute('data-handler', 'toggleClick');
liquid.registerHandler('toggleClick', {'click': someFunction});

18. Examples online
• All code is available at Github and NPM
• https://github.com/Zharktas/Liquid-Todo
• https://github.com/Zharktas/liquid.js
• https://www.npmjs.com/package/@zharktas/liquid.js
Jari-Pekka Voutilainen 18

19. Questions ?
@zharktas
Jari-Pekka Voutilainen
+358 40 553 8558
jari.voutilainen@iki.fi