PakyowUI

10 views
Skip to first unread message

bryanp

unread,
Jun 12, 2015, 8:20:29 AM6/12/15
to pak...@googlegroups.com
Hello! Just this week I pushed up code to that adds live updating views to Pakyow apps. I'd like to share a few details here, along with what the next steps look like.

There are two sides to this problem (client and server) and thus, two libraries. The first library, PakyowUI, watches for changes in application state and pushes updates to the proper clients through a WebSocket. The client-side library, Pakyow.js, receives updates and applies them to the rendered view. The view is never completely re-rendered; instead we only update the aspects that have changed.

This live updating behavior was one of the original goals of the framework. I'm excited to finally publish a working version of it!

To show a real example, I created a chat app in just a few lines of code.

Rationale

I wanted a way to build modern apps in a traditional backend-driven manner while still reaping the benefits of modern, live updating UIs. The existing approaches to building these modern UIs replace backend-driven architecture rather than extending it.

Instead of replacing traditional architecture, PakyowUI provides a layer on top of it. This allows Pakyow apps to remain accessible and fully usable in scenarios where real-time isn't supported (e.g. in the absence of WebSockets, JavaScript, etc).

In doing so, PakyowUI stays true to the fundamental nature of the web. It aims to be the real-time web expressed as progressive enhancement. It allows for any aspect of a website or web app to be updated in real-time, without any additional work by the developer.

Overview

At a high level, PakyowUI keeps rendered views (meaning views that are currently presented in a browser) in sync with the current state of the data. This works by keeping track of what views are currently rendered by a client, along with the data used to render those views.

When the data changes, a set of transformation instructions are sent to the proper client(s) where they are applied to reflect the new app state. The app does not push re-rendered views down to the client.

Say we have a rendered view that presents a user's name:

<div data-scope="user" data-id="1">
  <h3 data-prop="name">
    Bob Dylan
  </h3>
</div>

When the name changes, PakyowUI builds up an instruction like this:

[[:bind, { name: 'Thelonius Monk' }]]

This instruction is pushed to clients rendering User 1, where it's applied.

Predictably, the updated view reflects the new state:

<div data-scope="user" data-id="1">
  <h3 data-prop="name">
    Thelonius Monk
  </h3>
</div>

By expressing view transformations as data, they can be applied to any view by any interpreter; be it on the server or the client. This is enabled by how Pakyow separates logic from the view. The same view transformations that initially render the view are also enough to update the rendered view in the future. This is the first of many interesting features enabled by this separation.

What's Next

PakyowUI and Pakyow.js are functional and seem to work well, based on my testing. My plan is to include this code in the 0.10 release. Before it can be released, I'd like to improve the test suites (especially for Pakyow.js). More complete documentation also needs to be written. This is all in progress and I hope to have the next release out before the end of June.

To learn more I'd recommend going through the PakyowUI README and taking a look at the example app.

Happy to discuss any aspect of this!

-bryanp
Reply all
Reply to author
Forward
0 new messages