This repository contains the <chat-view> example app from the Data Flow in Polymer Elements and Apps talk at Polymer Summit 2016.

If you have questions or comments, please reach out to me on GitHub, Twitter (@graynorton) or Polymer's public Slack channel – I'm happy to discuss!

As of today (Oct 21, 2016), the files in this repo are still under-commented. I'd also like to add some additional information to this README, but I'm pushing to GitHub so that people can begin exploring. I'll try to flesh out the details soon.

1. Clone this repository
2. bower install
3. npm install

Once you have cloned and installed, check out the various branches (described below) to explore and compare the different versions of the app that were discussed in the talk.

To try the app out in your browser, you'll need to start a local web server, serving from the root of the project.

This 2016 <chat-view> example is based on the original from Kevin Schaaf's Thinking in Polymer talk at Polymer Summit 2015.

The purpose of this example app is to explore two different approaches to data flow in Polymer:

• Distributed | Bidirectional: The logic implementing the app's model is distributed across multiple components, with each individual component being responsible not only for rendering a view and capturing user interactions, but also for managing related aspects of the model. This approach leads to bidirectional data flow, as notifications of data mutations travel up the component hiearchy and back down to other components within the app.

• Centralized | Unidirectional: The app's model is centralized; all mutations occur in one place, with notifications flowing in only one direction – down the component hiearchy. Components deeper in the hierarchy are responsible only for rendering views and capturing user interacactions. Information about these interactions is conveyed via messages – actions in Flux / Redux parlance - to the centralized keeper of the model, which makes the corresponding mutations and flows notifications down.

• distributed: In this lightly modified version of the original app from Polymer Summit 2015, the <chat-thread-list> and <chat-thread-view> components are responsible for mutating the model in response to user actions. Two-way bindings and complex observers are used to propagate notifications of mutations between components, and to react to these notifications.

• centralized: All mutations occur in <chat-view>, flowing down to <chat-thread-list> and <chat-thread-view> via one-way bindings. Actions are conveyed upward via standard DOM events.

• redux: In this centralized version, the model is managed in a Redux store. The store is bound to the <chat-view> component using the polymer-redux library.

• redux-mono: In this variation on the redux version, instead of binding the store directly to <chat-view> or one of its child components, we bind it to a dedicated <chat-view-store> component that can be included within any app component that needs access to the store. (This is an example of the monostate pattern, because while multiple instances of <chat-view-store> may exist, they are all backed by a single instance of the store.) Although there's no good reason to do so in such a simple app, we include an instance of <chat-view-store> in <chat-thread-list> and another in <chat-thread-view> to show that choosing a centralized / unidirectional approach doesn't necessarily mean flowing every change from the top of your component hierarchy to the bottom.