React & Flux Workshop
11 likes•1,897 views
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.
React & Flux Workshop
- 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
- 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
- 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/
- 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