Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
React: Rethinking Best Practices Pete Hunt @floydophone
Give it five minutes. http://37signals.com/svn/posts/3124-give-it-five- minutes
Meet React. A library for creating user interfaces.
Meet React. Renders your UI and responds to events.
Meet React. AKA: The V in MVC
Meet React. Plays nicely with your stack, whatever it may be.
Rethinking Best Practices • Prerequisite – Combine DOM generation and display logic • React’s design – Re-render the whole...
1. Build components, not templates.
We all like separation of concerns, right?
Separation of concerns: Reduce coupling, increase cohesion.
Coupling is: “The degree to which each program module relies on each of the other modules.” http://en.wikipedia.org/wiki/C...
Cohesion is: “The degree to which elements of a module belong together.” http://en.wikipedia.org/wiki/Cohesion_(computer_s...
Templates encourage a poor separation of concerns. So are Angular-style directives.
“View model” tightly couples template to display logic. [{“price”: “7.99”, “product”: “Back scratcher”, “tableRowColor”: “...
Display logic and markup are inevitably tightly coupled. How do you find DOM nodes?
Display logic and markup are highly cohesive. They both show the UI.
Templates separate technologies, not concerns. And they do it by being deliberately underpowered.
Symptoms that your front-end technology is underpowered: Reliance on primitive abstractions (like {{> }} and {{#each }}).
Symptoms that your front-end technology is underpowered: Inventing lots of new concepts (that already exist in JavaScript).
From the Angular directives docs: “However isolated scope creates a new problem: if a transcluded DOM is a child of the wi...
The framework cannot know how to separate your concerns for you. It should only provide powerful, expressive tools for the...
This tool is a React component. A highly cohesive building block for UIs loosely coupled with other components.
Use components to separate your concerns. With the full power of JavaScript, not a crippled templating language.
Abstraction Composition Expressivity
Components are reusable.
Components are composable.
Components are unit testable. They are, after all, units.
What about spaghetti code?
Just don’t write spaghetti code. Keep your components small.
Just don’t write spaghetti code. Only put display logic in your components.
Just don’t write spaghetti code. “With great power comes great responsibility” – Uncle Ben in Spiderman
What about XSS?
React.DOM.a( {href: „http://instagram.com/floydophone‟}, „@floydophone on Instagram‟ );
What about working with designers?
JSX is an optional preprocessor to let you use HTML-like syntax. <a href=“http://instagram.com/floydophone”> @floydophone ...
JSX is an optional preprocessor to let you use HTML-like syntax. React.DOM.a( {href: „http://instagram.com/floydophone‟}, ...
With JSX, it’s easy for designers to contribute code.
The accessibility of templates and the power of JavaScript.
2. Re-render the whole app on every update The key design decision that makes React awesome.
Building UIs is hard because there is so much state. Lots of UI elements · Design iteration · Crazy environments · Mutable...
Data changing over time is the root of all evil.
“Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in ti...
In the 90s it was easier. Just refresh the page when the data changes.
When the data changes, React re- renders the entire component.
That is, React components are basically just idempotent functions. They describe your UI at any point in time, just like a...
Re-rendering on every change makes things simple. Every place data is displayed is guaranteed to be up-to-date.
Re-rendering on every change makes things simple. No magical data binding.
Re-rendering on every change makes things simple. No model dirty checking.
Re-rendering on every change makes things simple. No more explicit DOM operations – everything is declarative.
“Re-render on every change? That seems expensive.” “And doesn’t it mess up form fields and scroll position?”
3. Virtual DOM Makes re-rendering on every change fast.
You can’t just throw out the DOM and rebuild it on each update. It’s too slow and you’ll lose form state and scroll positi...
So we built a virtual DOM (and events system). Optimized for performance and memory footprint
On every update… • React builds a new virtual DOM subtree • …diffs it with the old one • …computes the minimal set of DOM ...
React’s architecture looks a lot like the Doom 3 engine
http://fabiensanglard.net/doom3/renderer.php
Game state / input Game logic Scene IR Render OpenGL ops GFX card http://fabiensanglard.net/doom3/renderer.php
App state / events React components Virtual DOM Compute DOM operations Browser http://fabiensanglard.net/doom3/renderer.php
It’s fast! Because the DOM is slow!
It’s fast! Computes minimal DOM operations
It’s fast! Batched reads and writes for optimal DOM performance
It’s fast! Usually faster than manual DOM operations
It’s fast! Automatic top-level event delegation (with cross-browser HTML5 events)
It’s fast! Provides hooks for custom update logic (though they’re almost never used)
It’s fast! Can do all this at 60fps, even in a (non-JIT) UIWebView on the iPhone.
The virtual DOM lets us do fun things. It can run in Node.js (new in 0.4)
The virtual DOM lets us do fun things. Optimizations based on app structure
The virtual DOM lets us do fun things. Testability for free
The virtual DOM lets us do fun things. SVG, VML and <canvas> support
The virtual DOM lets us do fun things. Running the whole app in a Web Worker (experimental)
Key takeaways
Components, not templates.
Re-render, don’t mutate.
Virtual DOM is simple and fast
Thanks for Rethinking Best Practices with me! http://reactjs.org/ #reactjs on Freenode IRC reactjs on Google Groups
Rethinking Best Practices
Rethinking Best Practices
Rethinking Best Practices
Upcoming SlideShare
Loading in …5
×
Technology
124,665 views
Sep. 26, 2013

Rethinking Best Practices

React is a different way to write JavaScript apps. When it was introduced at JSConf US in May, the audience was shocked by some of its design principles. One sarcastic tweet from an audience member ended up describing React’s philosophy quite accurately: https://twitter.com/cowboy/status/339858717451362304

We’re trying to push the limits of what’s possible on the web with React. My talk will start with a brief introduction to the framework, and then dive into three controversial topics: Throwing out the notion of templates and building views with JavaScript, “re-rendering” your entire application when your data changes, and a lightweight implementation of the DOM and events.

License: CC Attribution License
no profile picture user

  • Login to see the comments

Show More

Rethinking Best Practices

  1. 1. React: Rethinking Best Practices Pete Hunt @floydophone
  2. 2. Give it five minutes. http://37signals.com/svn/posts/3124-give-it-five- minutes
  3. 3. Meet React. A library for creating user interfaces.
  4. 4. Meet React. Renders your UI and responds to events.
  5. 5. Meet React. AKA: The V in MVC
  6. 6. Meet React. Plays nicely with your stack, whatever it may be.
  7. 7. Rethinking Best Practices • Prerequisite – Combine DOM generation and display logic • React’s design – Re-render the whole app on every update • React’s implementation – Virtual DOM and synthetic events
  8. 8. 1. Build components, not templates.
  9. 9. We all like separation of concerns, right?
  10. 10. Separation of concerns: Reduce coupling, increase cohesion.
  11. 11. Coupling is: “The degree to which each program module relies on each of the other modules.” http://en.wikipedia.org/wiki/Coupling_(computer_science)
  12. 12. Cohesion is: “The degree to which elements of a module belong together.” http://en.wikipedia.org/wiki/Cohesion_(computer_science)
  13. 13. Templates encourage a poor separation of concerns. So are Angular-style directives.
  14. 14. “View model” tightly couples template to display logic. [{“price”: “7.99”, “product”: “Back scratcher”, “tableRowColor”: “rgba(0, 0, 0, 0.5)”}]
  15. 15. Display logic and markup are inevitably tightly coupled. How do you find DOM nodes?
  16. 16. Display logic and markup are highly cohesive. They both show the UI.
  17. 17. Templates separate technologies, not concerns. And they do it by being deliberately underpowered.
  18. 18. Symptoms that your front-end technology is underpowered: Reliance on primitive abstractions (like {{> }} and {{#each }}).
  19. 19. Symptoms that your front-end technology is underpowered: Inventing lots of new concepts (that already exist in JavaScript).
  20. 20. From the Angular directives docs: “However isolated scope creates a new problem: if a transcluded DOM is a child of the widget isolated scope then it will not be able to bind to anything. For this reason the transcluded scope is a child of the original scope, before the widget created an isolated scope for its local variables. This makes the transcluded and widget isolated scope siblings.” http://docs.angularjs.org/guide/directive
  21. 21. The framework cannot know how to separate your concerns for you. It should only provide powerful, expressive tools for the user to do it correctly.
  22. 22. This tool is a React component. A highly cohesive building block for UIs loosely coupled with other components.
  23. 23. Use components to separate your concerns. With the full power of JavaScript, not a crippled templating language.
  24. 24. Abstraction Composition Expressivity
  25. 25. Components are reusable.
  26. 26. Components are composable.
  27. 27. Components are unit testable. They are, after all, units.
  28. 28. What about spaghetti code?
  29. 29. Just don’t write spaghetti code. Keep your components small.
  30. 30. Just don’t write spaghetti code. Only put display logic in your components.
  31. 31. Just don’t write spaghetti code. “With great power comes great responsibility” – Uncle Ben in Spiderman
  32. 32. What about XSS?
  33. 33. React.DOM.a( {href: „http://instagram.com/floydophone‟}, „@floydophone on Instagram‟ );
  34. 34. What about working with designers?
  35. 35. JSX is an optional preprocessor to let you use HTML-like syntax. <a href=“http://instagram.com/floydophone”> @floydophone on Instagram </a>
  36. 36. JSX is an optional preprocessor to let you use HTML-like syntax. React.DOM.a( {href: „http://instagram.com/floydophone‟}, „@floydophone on Instagram‟ )
  37. 37. With JSX, it’s easy for designers to contribute code.
  38. 38. The accessibility of templates and the power of JavaScript.
  39. 39. 2. Re-render the whole app on every update The key design decision that makes React awesome.
  40. 40. Building UIs is hard because there is so much state. Lots of UI elements · Design iteration · Crazy environments · Mutable DOM · User input · etc etc
  41. 41. Data changing over time is the root of all evil.
  42. 42. “Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible” – Dijkstra
  43. 43. In the 90s it was easier. Just refresh the page when the data changes.
  44. 44. When the data changes, React re- renders the entire component.
  45. 45. That is, React components are basically just idempotent functions. They describe your UI at any point in time, just like a server-rendered app.
  46. 46. Re-rendering on every change makes things simple. Every place data is displayed is guaranteed to be up-to-date.
  47. 47. Re-rendering on every change makes things simple. No magical data binding.
  48. 48. Re-rendering on every change makes things simple. No model dirty checking.
  49. 49. Re-rendering on every change makes things simple. No more explicit DOM operations – everything is declarative.
  50. 50. “Re-render on every change? That seems expensive.” “And doesn’t it mess up form fields and scroll position?”
  51. 51. 3. Virtual DOM Makes re-rendering on every change fast.
  52. 52. You can’t just throw out the DOM and rebuild it on each update. It’s too slow and you’ll lose form state and scroll position.
  53. 53. So we built a virtual DOM (and events system). Optimized for performance and memory footprint
  54. 54. On every update… • React builds a new virtual DOM subtree • …diffs it with the old one • …computes the minimal set of DOM mutations and puts them in a queue • …and batch executes all updates
  55. 55. React’s architecture looks a lot like the Doom 3 engine
  56. 56. http://fabiensanglard.net/doom3/renderer.php
  57. 57. Game state / input Game logic Scene IR Render OpenGL ops GFX card http://fabiensanglard.net/doom3/renderer.php
  58. 58. App state / events React components Virtual DOM Compute DOM operations Browser http://fabiensanglard.net/doom3/renderer.php
  59. 59. It’s fast! Because the DOM is slow!
  60. 60. It’s fast! Computes minimal DOM operations
  61. 61. It’s fast! Batched reads and writes for optimal DOM performance
  62. 62. It’s fast! Usually faster than manual DOM operations
  63. 63. It’s fast! Automatic top-level event delegation (with cross-browser HTML5 events)
  64. 64. It’s fast! Provides hooks for custom update logic (though they’re almost never used)
  65. 65. It’s fast! Can do all this at 60fps, even in a (non-JIT) UIWebView on the iPhone.
  66. 66. The virtual DOM lets us do fun things. It can run in Node.js (new in 0.4)
  67. 67. The virtual DOM lets us do fun things. Optimizations based on app structure
  68. 68. The virtual DOM lets us do fun things. Testability for free
  69. 69. The virtual DOM lets us do fun things. SVG, VML and <canvas> support
  70. 70. The virtual DOM lets us do fun things. Running the whole app in a Web Worker (experimental)
  71. 71. Key takeaways
  72. 72. Components, not templates.
  73. 73. Re-render, don’t mutate.
  74. 74. Virtual DOM is simple and fast
  75. 75. Thanks for Rethinking Best Practices with me! http://reactjs.org/ #reactjs on Freenode IRC reactjs on Google Groups

×