The document discusses the integration of React with Meteor, emphasizing the benefits of declarative programming and the management of state complexity. It highlights the distinctions between various programming paradigms, including functional and reactive programming, and presents advantages such as virtual DOM efficiency, one-way data flow, and the fast reactive communication facilitated by Meteor. Additionally, it addresses the collaboration between React and Meteor, including how to utilize them effectively in building seamless user experiences.

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!