Isomorphic Flux

Isomorphic Flux Michael Ridgway @TheRidgway [email protected]

React and Flux patterns can be used to build the
holy grail of isomorphic applications.

Isomorphic The ability to perform similar functionality in multiple environments

Agenda ▪ Why Isomorphic? ▪ Isomorphic Spectrum ▪ Achieving the
Holy Grail ▪ Flux Chat ▪ Problems to Address

Why Isomorphic?

Server Rendering ▪ Search engine optimization ▪ Legacy browser support
▪ User perceived performance

▪ Rich client interactions ▪ Faster page navigation ▪ No
re-downloading assets every page ▪ No re-fetching data every page ▪ Just load the new data and new assets if needed Single Page Apps

Why not both? All of the benefits of each AND
we don’t have to duplicate code!

First Principle of Rich Web Apps “server-rendered apps vs single-page
apps: If we want to optimize for the best possible user experience and performance, giving up one or the other is never a good idea.” - Guillermo Rauch http://rauchg.com/2014/7-principles-of-rich-web-applications/

Isomorphic Spectrum

Fully Independent Client Server Model View Controller Model View Controller
Routing Routing

Converging Client Server Model Controller Model View Routing Routing Controller

Client Controller Model View Routing Server

Mojito was Yahoo’s first take on isomorphic MVC • Used
YUI on the server and the client Lessons learned: • Browser abstractions are too slow for the server • Synchronizing server, client, and DOM was hard • Using YUI’s module format was problematic in node.js

Achieving the Holy Grail

Low Hanging Fruit ▪ Use CommonJS or ES6 instead of
mixing formats ▪ Use polyfills instead of abstractions where possible ▪ es5-shim, intl.js, etc. ▪ Use libraries that are shareable ▪ lodash, superagent, moment, etc. ▪ Use bundling for building your javascript ▪ e.g. webpack or browserify

React ▪ Works on the server and the client with
one simple API change: ▪ Client: React.render(Component(), domElement, callback); ▪ Server: var html = React.renderToString(Component()); ▪ Clean programmatic page composition using components ▪ DOM synchronization is easy, now only worry about state management

Flux ▪ Provides clean unidirectional application flow ▪ Describes where
state management happens (stores) ▪ Decouples model dependencies by using event handlers

But flux is for the client side right? Let’s decompose
the Flux flow to figure out how it could be used on the server

Working Backwards React Component React Components

Working Backwards Stores React Component React Components Component needs to
render based on a certain state from a store

Working Backwards Dispatcher Stores React Component React Components Stores are
populated by actions from the dispatcher Component needs to render based on a certain state from a store

Working Backwards Action Creator Actions are dispatched through the dispatcher
from action creators Dispatcher Stores React Component React Components Stores are populated by actions from the dispatcher Component needs to render based on a certain state from a store

You can achieve any application state through some set of
action creator calls.

Action Creator Dispatcher Stores React Component React Components HTTP request
once completed Proposed Server Flow

Flux Chat

var React = require('react'); var ChatApp = React.createFactory(require('./components/ChatApp.jsx')); var showMessages
= require('./actions/showMessages'); React.render(ChatApp(), document.getElementById('app'), function (err) { if (err) { throw err; } showMessages(); }); client.js <html> <head> <title>Chat</title> </head> <body> <div id="app"> </div> </body> <script src="./build/js/client.js"></script> </html> index.html

var messages = require('../data/messages'); var dispatcher = require('../lib/dispatcher'); module.exports =
function () { dispatcher.dispatch({ type: 'RECEIVE_MESSAGES', messages: messages }); }; actions/showMessages.js var Dispatcher = require('flux').Dispatcher; module.exports = new Dispatcher();

var React = require('react'); var ChatApp = require('./components/ChatApp.jsx'); var showMessages=
require('./actions/showMessages'); server.get('/', function (req, res, next) { showMessages(); var html = React.renderToString(ChatApp()); res.write('<html><head><title>Chat</title></head>'); res.write('<body>'); res.write('<div id="app">' + html + '</div>'); res.write('</body>'); res.write('<script src="/build/js/client.js"></script>') res.write('</html>'); res.end(); }); server.js

What if the data is fetched asynchronously?

server.get('/', function (req, res, next) { showMessages({}, function (err) {
if (err) { next(err); return; } var html = React.renderToString(ChatApp()); res.write('<html><head><title>Chat</title></head>'); res.write('<body>'); res.write('<div id="app">' + html + '</div>'); res.write('</body>'); res.write('<script src="/build/js/client.js"></script>') res.write('</html>'); res.end(); }); }); server.js add callback

Concurrency Issues ▪ Data is being shared between requests ▪
Personal data could be leaked ▪ We’ll have to scope the data to the request

Scoping the Store ▪ Singletons are holding global data ▪
Let’s make stores classes that are instantiated per request

Scoping the Dispatcher ▪ Now that the store is a
class, registration of the handler needs to be done for the instance ▪ Dispatches should be scoped to the request too, so that data isn’t sent to every request’s store instance

Dispatchr ▪ Register classes to the dispatcher instead of static
functions ▪ Instantiate a new Dispatchr per request ▪ Dispatchr creates instances of stores as they are needed and dispatches the actions https://github.com/yahoo/dispatchr

lib/dispatcher.js var Dispatcher = require('flux').Dispatcher; module.exports = new Dispatcher(); var
Dispatcher = require('dispatchr')(); var MessageStore = require('../stores/MessageStore'); Dispatcher.registerStore(MessageStore); module.exports = Dispatcher;

Now the showMessage action creator (and all action creators) need
access to the dispatcher instance to call dispatch()

The components need to be able to retrieve state from
the store instance

= React.createClass({ getInitialState: function () { return { messages: MessageStore.getAllMessages() } }, render: function () { // ... } }); module.exports = ChatApp; components/ChatApp.jsx

= React.createClass({ getInitialState: function () { var dispatcher = this.props.dispatcher; return { messages:dispatcher.getStore(MessagesStore).getAllMessages() } }, render: function () { // ... } }); module.exports = ChatApp; components/ChatApp.jsx

Full server-side, request-scoped Flux!

Overview of Changes ▪ Store instances instead of singletons ▪
Dispatcher instance instead of singleton ▪ Passing dispatcher instance to action creators and components that need it

And with the same changes to the client, it all
still works client-side too!

But why do we need to execute the action again?
The server already got us to the state we want. Propagate your state from server to client!

var html = React.renderToString(ChatApp({ dispatcher: dispatcher })); res.expose(dispatcher.dehydrate(), 'App'); res.write('<html><head><title>Chat</title></head>');
res.write('<body>'); res.write('<div id="app">' + html + '</div>'); res.write('</body>'); res.write('<script>' + res.locals.state + '</script>'); res.write('<script src="/build/js/client.js"></script>'); res.write('</html>'); res.end(); server.js var express = require('express'); var expstate = require('express-state'); var server = express(); expstate.extend(server);

You can see all of the code for this simplified
chat example https://github.com/mridgway/isomorphic-chat

Problems to Address

Naming between actions, action creators, and component interactions can be
confusing I’ve probably slipped up countless times throughout this presentation

Dispatcher (or some scoped wrapper) needs to be passed around
to all components that need it React’s undocumented context could solve this, but unsure of stability of the API

Knowing which actions we should execute is based on which
components are going to be rendered No way to know which components are being rendered. Need some step between a full component hierarchy and being rendered to a string.

Fluxible Libraries

fluxible-app Container for isomorphic Flux applications • Wrapper around Dispatchr
• Provides clean APIs for constructing isomorphic flux applications • Removes boilerplate • Enforces unidirectional flow by restricting interfaces • Pluggable: add new interfaces

fluxible-plugin-routr Adds isomorphic routing interfaces to your fluxible-app • Shared
routes between server and client • Shared route matching logic • Create paths from components using routes names and parameters • Example: context.makePath(‘user’, { id: 1 }) // returns /user/1

fluxible-plugin-fetchr Adds isomorphic CRUD interfaces to your fluxible-app • Create
server side web services • Expose them via an XHR endpoint • Access your services from an action with the same code both server and client • Example: context.service.read(‘messages’, {/*params*/}, callback) • Client uses XHR, server calls service directly

flux-router-component Provides components and mixins for handling client routing •
<NavLink> component that fires built-in `navigate` action creator • Navigate action creator dispatches matched route • App level mixin handles route changes from your store and triggers window pushstate

flux-examples Example applications using all of the above libraries github.com/yahoo/flux-examples

Links ▪ https://github.com/yahoo/fluxible-app ▪ https://github.com/yahoo/fluxible-plugin-fetchr ▪ https://github.com/yahoo/fluxible-plugin-routr ▪ https://github.com/yahoo/fetchr ▪
https://github.com/yahoo/dispatchr ▪ https://github.com/yahoo/flux-examples Thanks! Contact ▪ Michael Ridgway ▪ @TheRidgway ▪ [email protected]

Isomorphic Flux

Isomorphic Flux

Featured

Transcript