This document outlines an agenda for a workshop on React and Flux. The workshop will begin with light introductions to React and Flux concepts, followed by demos of building applications with each. More details on React and Flux will be provided. Code repositories for the demos will be shared. The workshop aims to convey high-level concepts like components, one-way data flow, and separation of concerns between views and data. Recipes for conditional content and collections will be demonstrated.

1. REACT & FLUX WORKSHOP
BY CHRISTIAN LILLEY
ABOUT.ME/XML — @XMLILLEY

2. OUR PLAN
REACT
1. Light Intro to React Concepts
2. Demos: Building with React
3. React Details/Summary
(SHORT) BREAK
FLUX
4. Light Intro to Flux Concepts
5. Demos: Building with Flux
6. Flux Details/Summary

3. CODE
REPOS AT GITHUB.COM/XMLILLEY
github.com/xmlilley/jschannel-react-demos
github.com/xmlilley/jschannel-flux-demos
“WORKSHOP” VS. “HANDS-ON”
NORMS ON QUESTIONS

7. WATCH FOR: THE BIG PICTURE
Components, Components
Components
Dumb Components,
Decoupled Systems
Location-Transparent
Messaging: Actions &
Events
Crossover with Node
The Unix Philosophy
Modules & Explicit
Dependency Injection
Everything-in-JS
Virtual DOM
… which is really about…
Separating Render Context
(DOM) from App
Architecture
One-Way Flows (data &
directed trees), FRP,
Immutability
“Being DOM vs. Rendering
via DOM”

8. WATCH FOR: THE BIG PICTURE
DOM —> JAVASCRIPT?
JAVASCRIPT —> DOM
or:

9. WATCH FOR: THE BIG PICTURE
$WATCH & UPDATE?
RE-RENDER
or:

10. WATCH FOR: THE BIG PICTURE

11. WHAT IS ?
‘Library’, not a ‘Framework’
If you start from MVC, React is only the V
(But forget MVC. It’s kind of… over)
Components for interfaces: Make complex
components from simpler components
Not a tiny library, but a small API: only for rendering
components, not building whole apps
Use basic JS for most things, not API calls

12. Browser Support: IE 8+ (Needs shims/shams for ES5)
The whole interface is a tree of React components,
which mirrors… is mirrored by… the DOM tree
For every DOM element, there’s a component
No templates at runtime: only Javascript *
Data flows only in one direction: down the tree
Conceptually, this means we never ‘update’ or
‘mutate’ the DOM. We simply re-render it.
WHAT IS ?
* YMMV

13. LET’S SEE A COMPONENT…

14. COMPONENT STRUCTURE
A component is a React ‘class’ instance (but isn’t built
with `new` in ES5: it’s functional construction until ES6)
Components have default ‘lifecycle’ methods: hooks for
actions at various points in time
has ‘Props’ & ‘State’: props are immutable and inherited,
state is mutable and changes trigger re-render
JSX is how you compose the view, combine child
elements
Extend with your own methods, or augment existing ones

15. COMPONENT MIXINS
Mixins are handy bundles of reusable methods that
you can apply to multiple component types
Great for ‘glue’ functions/boilerplate: service
interaction, event listeners, dispatching Actions, etc.
Big problem: they’re going away in ES6
Smaller problem: multiple mixins can clash
Good Solution to both: ‘Higher-Order
Components’ (functional generators that compose
new components by augmenting existing ones)

16. ‘RULES’ ON PROPS & STATE
‘state’ vs. ‘props’ isn’t about the kind of thing, instead
it’s how thing is used and where it came from
a given thing is ‘state’ in the one place where you can
modify it: any child using same thing inherits as a
‘prop’, which can’t be modified
Avoid retrieving same data at different levels of the
tree: instead, pass it down as props
Pass functions (as props) so children can trigger
updates on ancestor’s state, then render new props

17. JSX IS XML-LIKE JAVASCRIPT
Everything in React is Javascript, including your ‘template’
You can compose a React component’s view in raw
Javascript objects, but you don’t really want to.
Plus, we’re really used to HTML. It’s painful for us to
imagine creating web interfaces without it.
HTML/XML is actually a really good way to visually model
a tree structure of parent-child relationships
Hence, JSX is a syntax that looks like XML/HTML… but
isn’t. We transpile it to React’s fundamental JS.

18. JSX IS XML-LIKE JAVASCRIPT
React.createElement("div", {className: "ideas-wrapper"},
React.createElement("div", {className: "bs-callout bs-
callout-warning"},
React.createElement("p", null, “Lorem Ipsum dolor
est.…”)
),
React.createElement(Button, {bsStyle: "success",
bsSize: "small", onClick: this._showNewIdeaModal},"New
Idea"),
React.createElement(NewIdeaModal, {closeFunc:
this.closeModal, show: this.state.showModal}),
React.createElement(UserselectedIdea, null),
React.createElement(IdeaList, null)
)
INSTEAD OF THIS DEEPLY-NESTED MESS…

19. JSX IS XML-LIKE JAVASCRIPT
<div className="ideas-wrapper">
<div className="bs-callout bs-callout-
warning">
<p>Lorem Ipsum dolor est…</p>
</div>
<Button bsStyle='success' bsSize='small'
onClick={this._showNewIdeaModal}>New Idea</
Button>
<NewIdeaModal closeFunc={this.closeModal}
show={this.state.showModal} />
<UserselectedIdea />
<IdeaList />
</div>
…JSX LETS US HAVE THIS:

20. JSX SYNTAX ESSENTIALS
If your JSX spans multiple lines, wrap in parens
Components are ‘classes’, so uppercase 1st letters
lowercase for traditional html elements
camelCase most attributes
reserved words: ‘class’=‘className’; ‘for’=‘htmlFor’
single curly brackets to interpolate: {obj.prop}
wrap comments: {/*comment in JSX Block*/}

21. JSX SYNTAX ESSENTIALS
Remember: even <div> is just a default React
component, called ‘div’, which has a render method
that outputs some specific HTML

22. THE LIFE OF A COMPONENT
Creation
Get State &
Props
render( )
DOM
Interaction:
handlers,
:focus, etc.
DOM Events
(or store
updates)
Action/Event
Handler
setState( )

23. THE LIFE OF A COMPONENT
Component ‘lifecycle methods’ run the process:
Source: javascript.tutorialhorizon.com

24. THE LIFE OF A COMPONENT
componentDidMount()
add DOM event listeners, fetch
async data, animate something,
claim focus for an input, etc. Use
JQuery or attach stuff from other
libraries (only runs on browser, not
server)
componentDidUpdate()
like componentDidMount, for
updates: good for animation hooks,
focus grabs, etc.
componentWillUnmount()
cleanup: remove event listenters,
timers, etc
shouldComponentUpdate()
(advanced): to prevent a re-render
that would otherwise happen
componentWillReceiveProps
(advanced) monitor if props have
changed between renders
componentWillMount()
(advanced) no DOM yet. Last
chance to change state with
conditional logic without triggering
re-render
componentWillUpdate()
(advanced) Like
componentWillMount, for updates

25. RE-RENDERING COMPONENTS
setState() updates are batched, nodes marked as ‘dirty’
Source: Christopher Chedeau - calendar.perfplanet.com/2013/diff/

26. RE-RENDERING COMPONENTS
All dirty elements & children are re-rendered together
Source: Christopher Chedeau - calendar.perfplanet.com/2013/diff/

27. RE-RENDERING COMPONENTS
It’s possible to prevent renders: shouldComponentUpdate()
Source: Christopher Chedeau - calendar.perfplanet.com/2013/diff/

28. CONTROLLER-VIEWS
aka: ‘view controller’, ‘owner’, ‘stateful component’
"Try to keep as many of your components as possible stateless.
By doing this you'll isolate the state to its most logical place
and minimize redundancy, making it easier to reason about your
application.” —React Team
several stateless components that just render data, &
a stateful parent component that passes its state to
children via props
stateful component encapsulates all of the interaction
logic

29. REACT RECIPES:
CONDITIONAL CONTENT

30. REACT RECIPES:
CONDITIONAL CONTENT

31. REACT RECIPES:
CONDITIONAL CONTENT

32. REACT RECIPES:
COLLECTIONS/NG-REPEAT

33. REACT RECIPES:
COLLECTIONS/NG-REPEAT

34. REACT CONCLUSIONS
React components not so different conceptually
than Angular Directives or Ember Components:
small, decoupled, easy-to-change
But very different implementation
The only ‘magic’ is really the algorithms for diffing
and child-reconciliation, which is a very narrow
concern: everything else is right there for you to see
A bit more typing during creation (use tools!)
NOT a full application framework

35. STRETCH!

36. WHAT IS ?

37. WHAT IT’S TRYING TO IMPROVE:

38. WHAT IS ?
"It's more of a pattern rather than a formal
framework.” —Facebook
“It is simply a new kind of architecture that
complements React and the concept of
Unidirectional Data Flow.” — Scotch.io
“The glue for communicating between your dumb
React components” — XML
Very little of ‘Flux’ is a set library or API: most of it
you create yourself, or BYO tools

39. WHAT IS ?
Doesn’t even include everything you need: there’s
no router, for instance
Basic Javascript conventions wherever possible
Tendency toward the Node/NPM world
Fragmented/Evolving

40. THE FOUR HORSEMEN: ADSV
Actions — Users & Services Do
Things
Dispatcher — Notify Everyone
What Happened
Stores — Keep Track of the Data
Views — React Components

41. GO WITH THE (1-WAY) FLOW

42. A FULLER PICTURE

43. ENOUGH TALKY-TALK.
SHOW CODE!!!

45. FLUX: ACTIONS
Discrete, atomic bits of app logic: “When X happens,
Do Y and Z to data/app state”
As close as it gets to the MVC ‘Controller’
“Fire and Forget”: use events, not callbacks
Usually where server calls are triggered
Then, tell everyone the outcome, via the Dispatcher
Best-practices: separate action types, use ‘action-
constants’

46. FLUX: DISPATCHER
Only one instance per app
Just a dumb pipe: the internet, not the nodes
All subscribers receive all events it dispatches
Only clever trick: waitFor()

47. FLUX: STORES
How many? Approx. one store per entity type/domain
Or, to model a relationship between entities
Simply accepts incoming changes, fires change
events, lets the components worry about what
happens next
Smart about data,
dumb about interface & interaction
Can also store app-wide user/interface state

48. FLUX: STORES
Flux is completely unopinionated about models:
POJOs seem most common
Consider Immutable data-structures

49. REACT/FLUX RECIPES:
TWO-WAY BINDINGS
Do we really use this all that often? :-)
Simple concept:
One component updates state from input
Another component listens for state changes
Can do yourself, or use ‘LinkedStateMixin’
(Only saves a few lines of code…)

50. FLUX/REACT CONCLUSIONS
Powerful patterns make it harder to mingle
concerns, create interdependency
Less ‘magic’
Community/docs still growing… quickly
Everything is user-replaceable, many options
Maintainability vs. Creation Speed
Lots of Developer Freedom (too much for some?)

51. FLUX/REACT CONCLUSIONS
Not everyone is ready to give up HTML templating
… yet
Mass-adoption might require a ‘framework’
around it
A sponsor is helpful, too: Facebook?
Clearly the direction our craft is moving… but
they’re not the only ones moving that way, nor is it
the only way to get there

52. REACT & VIRTUAL DOM
If you do your whole interface in HTML, what is
that? It’s a virtual DOM.
So, we’ve always been doing that. That’s not the
magic here.
More powerful ideas:
Immutable DOM
Optional (Decoupled) DOM

53. ABOUT PERFORMANCE:
The React team talks in frames per second when
describing their lightning fast rendering. Examples such
as this one show lists of 1500 rows taking 1.35 seconds
with AngularJS versus 310ms with ReactJs. This begs
questions such as:
• should you ever render 1500 rows (can the user
process this much on screen) and
• is trimming fractions of a second off of load times on
reasonably designed pages a premature optimization
in most applications?
Source: http://www.funnyant.com/reactjs-what-is-it/

54. ABOUT PERFORMANCE:
Source: aerotwist.com/blog/react-plus-performance-equals-what/

55. ABOUT PERFORMANCE:
The pattern is more important than the hype
Properly-optimized, and used normally, other tools
(Angular, Ember) perform fairly comparably
Go ahead and mix React into your existing apps
for performance gains. Keep React (or something
similar) for the pattern.

56. EXTRAS: TESTING
Atomic modules/components == easier testing
explicit dependency injection == easier testing
JEST: Jasmine +++
automatically mocks dependencies for you
includes a runner (kinda like React’s Karma)
Output of a React component is absolute: a string
just compare the strings
Type assertion for props is complementary

57. EXTRAS: ANIMATION
Built-In support for CSS animation quite similar to
Angular in some ways
Much more explicit, non-automatic
ReactTransitionGroup: excellent pattern of
encapsulating reusable functionality on an
invisible wrapper element, rather than augmenting
in-view components
That said… Javascript animation is sexy again,
particularly when all renders are already in
requestAnimationFrame()

58. EXTRAS: NAMESPACING
var MyFormComponent = React.createClass({...});
MyFormComponent.Row = React.createClass({…});
module.exports = MyFormComponent;

59. EXTRAS: CSS
Why are inline styles ‘bad’? Not maintainable.
Goals for CSS are narrower scoping, avoiding cascade
collisions. (See BEM, OOCSS)
This is very hard with global styles: either single-element
classes, or single-rule classes. Neither is convenient.
JS can do anything a CSS preprocessor can do, and more.
In JS. No pre-processing.
Not inherently superior, but very attractive.

60. EXTRAS: TOOLS, RESOURCES
github.com/facebook/react/wiki/Complementary-Tools
React Bootstrap already exists, of course
Redux, Reflux, Alt are hottest Flux replacements
Axios for networking ($http)
React-Router
React-Mount, if you really like DOM —> Javascript
React-Style: CSS-in-JS

61. BY CHRISTIAN LILLEY
ABOUT.ME/XML — @XMLILLEY
THANK YOU!!!!
-XML