react & flux workshop
TRANSCRIPT
REACT & FLUX WORKSHOPBY CHRISTIAN LILLEY ABOUT.ME/XML — @XMLILLEY
OUR PLANREACT 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
CODEREPOS AT GITHUB.COM/XMLILLEY
github.com/xmlilley/jschannel-react-demos github.com/xmlilley/jschannel-flux-demos
“WORKSHOP” VS. “HANDS-ON” NORMS ON QUESTIONS
WATCH FOR: THE BIG PICTUREComponents, 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”
WATCH FOR: THE BIG PICTURE
DOM —> JAVASCRIPT?
JAVASCRIPT —> DOMor:
WATCH FOR: THE BIG PICTURE
$WATCH & UPDATE?
RE-RENDERor:
WATCH FOR: THE BIG PICTURE
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
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
LET’S SEE A COMPONENT…
COMPONENT STRUCTUREA 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
COMPONENT MIXINSMixins 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)
‘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
JSX IS XML-LIKE JAVASCRIPTEverything 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.
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…
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:
JSX SYNTAX ESSENTIALSIf 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*/}
JSX SYNTAX ESSENTIALSRemember: even <div> is just a default React component, called ‘div’, which has a render method that outputs some specific HTML
THE LIFE OF A COMPONENTCreation
Get State & Props
render( )DOM
Interaction: handlers,
:focus, etc.
DOM Events (or store updates)
Action/EventHandler
setState( )
THE LIFE OF A COMPONENTComponent ‘lifecycle methods’ run the process:
Source: javascript.tutorialhorizon.com
THE LIFE OF A COMPONENTcomponentDidMount() 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
RE-RENDERING COMPONENTSsetState() updates are batched, nodes marked as ‘dirty’
Source: Christopher Chedeau - calendar.perfplanet.com/2013/diff/
RE-RENDERING COMPONENTSAll dirty elements & children are re-rendered together
Source: Christopher Chedeau - calendar.perfplanet.com/2013/diff/
RE-RENDERING COMPONENTSIt’s possible to prevent renders: shouldComponentUpdate()
Source: Christopher Chedeau - calendar.perfplanet.com/2013/diff/
CONTROLLER-VIEWSaka: ‘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 propsstateful component encapsulates all of the interaction logic
REACT RECIPES: CONDITIONAL CONTENT
REACT RECIPES: CONDITIONAL CONTENT
REACT RECIPES: CONDITIONAL CONTENT
REACT RECIPES: COLLECTIONS/NG-REPEAT
REACT RECIPES: COLLECTIONS/NG-REPEAT
REACT CONCLUSIONSReact 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
STRETCH!
WHAT IS ?
WHAT IT’S TRYING TO IMPROVE:
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
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
THE FOUR HORSEMEN: ADSVActions — Users & Services Do ThingsDispatcher — Notify Everyone What Happened Stores — Keep Track of the DataViews — React Components
GO WITH THE (1-WAY) FLOW
A FULLER PICTURE
ENOUGH TALKY-TALK.SHOW CODE!!!
FLUX: ACTIONSDiscrete, 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’
FLUX: DISPATCHEROnly one instance per app
Just a dumb pipe: the internet, not the nodes
All subscribers receive all events it dispatches
Only clever trick: waitFor()
FLUX: STORESHow 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
FLUX: STORESFlux is completely unopinionated about models: POJOs seem most common
Consider Immutable data-structures
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…)
FLUX/REACT CONCLUSIONSPowerful 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?)
FLUX/REACT CONCLUSIONSNot 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
REACT & VIRTUAL DOMIf 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
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/
ABOUT PERFORMANCE:
Source: aerotwist.com/blog/react-plus-performance-equals-what/
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.
EXTRAS: TESTINGAtomic 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
EXTRAS: ANIMATIONBuilt-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()
EXTRAS: NAMESPACINGvar MyFormComponent = React.createClass({...}); MyFormComponent.Row = React.createClass({…});
module.exports = MyFormComponent;
EXTRAS: CSSWhy 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.
EXTRAS: TOOLS, RESOURCESgithub.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