Meteor and React boast declarative philosophies, making the two of them a great pairing for managing state.

1. React + Meteor
Declarative JS with Sensible State

2. Taggart
Bowen-Gaddy
Campus Bubble (Previous)
• Built MVP with Meteor 0.6
• Moved to Backbone/React client, Meteor server
Insightpool (Current)
• Adopted a monolithic Rails app
• Built a React / Flux client from the ground up

3. Assertions
• Dogmatic design decisions can limit you
◦ Separation of concerns are your concern
• Declarative programming helps manage complexity in
state
• FRP across your system makes fully declarative
programming reasonable
• Philosophies of React & Meteor assume the above

4. Definitions
• Declarative Programming
◦ Describing “what” to do to data in different states, often leaving the
implementation details up to a language/framework
• Imperative Programming
◦ In contrast, describing “how" to achieve a desired state
• Functional Programming
◦ Describing functions that mutate data to achieve a declared state
• Reactive Programming
◦ Your code reacts to state changes, allowing your declarations to propagate &
change state deeper in your “data flow”
• Functional Reactive Programming (FRP)
◦ Using your functional blocks to achieve a reactive flow

5. React
• Just the UI
◦ Lots of people use React as the V in MVC. Since React makes no
assumptions about the rest of your technology stack, it's easy to
try it out on a small feature in an existing project.
• Virtual DOM
◦ React uses a virtual DOM diff implementation for ultra-high
performance. It can also render on the server using Node.js — no
heavy browser DOM required.
• Data Flow
◦ React implements one-way reactive data flow which reduces
boilerplate and is easier to reason about than traditional data
binding.

6. Flux
• Facebook’s response to MVC
• One-way data flow
• Data architecture, not a framework
◦ Many implementations

7. React Native
• “Learn once, write anywhere"
• Released today!
• Compiles to native code
◦ No webviews

8. Meteor
• One language everywhere
◦ Isomorphic APIs mean that the same code, written in the same
language, can run on both client and server.
• Live Updates
◦ Data updates live on the screen as it changes. Users can
collaborate seamlessly.
• Ultra Responsive
◦ Changes made by a user are instantly visible, without the
unprofessional laggy feeling that would result from waiting for a
round trip to the server.

9. How?
• Blaze
◦ Reactive templating library, similar to React
• Tracker
◦ FRP implementation
• DDP
◦ Fast, out-of-the-box reactive communication between the
client and the server
• Livequery / minidatabases
◦ The ability to query and update seamlessly between client and
server means isomorphic FRP is possible

10. React Compliments Meteor
• React is Fast
◦ Virtual DOM diffing out-performs all other client-side re-rendering libraries
• React is full-featured and built to manage your view state
◦ Blaze is only a templating system
◦ Blaze is tightly coupled with your Collections
• Predictable, re-usable components
◦ Sharable, discrete, (FUNCTIONAL / REACTIVE!), components only
possible by re-thinking your separation of concerns
• Serverside rendering
◦ Print to a string, serve up first for SEO or performance
• Take advantage of the ecosystem surrounding it

11. Meteor compliments React
• React is ONLY the “view layer”
◦ Needs a “store” or a “model” to manage the data’s state
• Flux is not an out-of-the-box solution
◦ The ecosystem is still very much “in flux” and trying to figure out
best practices
• Meteor’s Latency Compensation + React’s reactive nature
and fast diffing are a perfect pairing
• Having livequery / minidatabases available to React means
less boilerplate and easy access to the data that view needs

12. Does this actually work?
YEAH!
github.com/reactjs/react-meteor

13. How?
• Hooks into React’s first-class + exposed lifecycle
functions to manage reactively setting state
• Allows React components to be dropped into Blaze
templates
• Meteor manages pubsub of model state + logic
• React manages DOM manipulation and view state + logic

14. Lets look at some code
• Leaderboard
• Session.set() vs this.setState()

15. Other options?
Arunoda’s Flow Components
• Not react, but VERY heavily inspired by it
• Doesn’t “re-draw” as many lines RE: separations of
concerns
• Lives in the meteor ecosystem
◦ These are still Blaze templates
github.com/meteorhacks/flow-components

16. Other options?
Tmeasday’s Leaderboard example
• Takes advantage of ES6 + newer React paradigms
◦ Destructuring + Rest parameters
◦ PropTypes
◦ RenderToString()
http://blog.percolatestudio.com/engineering/reactive-user-interfaces/

17. Other options?
Roll your own!!

18. Also
React’s creator, Pete Hunt:
https://www.meteor.com/blog/2014/02/14/
pete-hunt-talks-facebook-react

19. React + Meteor
Questions & Answers!