ReactJS Code Impact
•Download as PPTX, PDF•
9 likes•3,086 views
Slides from my (incomplete) ReactJS presentation at Code Impact in Jacksonville, Florida, 9/13/2014. Will update these after my next presentation that will include more on the Flux architectural pattern
![This Guy
• Software Engineer at feature[23]
• I can haz degrees in muzak and puterz
• I beer, fish, and party on guitars
• I currently dig FRP, IOT, and JS (the good parts…)](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to ReactJS Code Impact
Similar to ReactJS Code Impact (20)
Recently uploaded
Recently uploaded (20)
ReactJS Code Impact
- 1. React JS
- 2. This Guy • Software Engineer at feature[23] • I can haz degrees in muzak and puterz • I beer, fish, and party on guitars • I currently dig FRP, IOT, and JS (the good parts…)
- 3. So, What Is React? • A JavaScript library for building User Interfaces* • It was created by the engineering team at facebook • https://code.facebook.com/projects/ • A (Smart) View Engine of sorts • It is not a client-side, MVC/MVVM/MW*, framework
- 4. What Does React Do? • React renders your UI • React responds to user interactions • React reduces complexity • React tackles performance issues for you, behind the scenes
- 5. This Sounds Familiar • It is… and isn’t • http://www.todomvc.com • Two-way data binding is great… and isn’t • Cascading effects and interdependent data • State over time • Templates are great… until they aren’t • Constrained Template Engines/Languages • Cohesion over Coupling • Templates don’t respect state • Frameworks are great… and aren’t • Just a View Engine, and just JavaScript • Truly reusable and plays nicely with existing frameworks and libraries • No esoteric concepts
- 6. React Concepts Notions • Components • Manage their own state • Handle interactions through explicit and declarative events • Separate responsibilities • Higher maintainability • Great for debugging • Great for testing • Props • Data that is passed to a component • Immutable • State • Immutable… sort of • this.setState() • “Re-render” entire app on state change • This sounds horribly inefficient… No esoteric concepts?!?! …these aren’t new concepts
- 7. Virtual DOM (this is) • A virtual, in memory, representation of the real DOM • Changes in the real DOM trigger changes to the state of your React Component • When state changes, React creates a new representation of the virtual DOM based on what has changed. • React diffs between the original representation and the new representation of the Virtual DOM. • React determines the minimal set of operations necessary to update the real DOM and batch processes them as a patch to the real DOM. • In effect, you have “re-rendered” your application, but you haven’t lost any state in the real DOM (scroll position, timers, etc.)
- 8. Why a Virtual DOM? • Because the real DOM is slow and clunky • …and you don’t know all the implications of changing DOM or Style • http://www.csstriggers.com • Because “re-rendering” your entire application every time state changes would be unbelievably slow (a la 1990s style page refreshes) in the modern web. • But those 90s people had some things right • Wrapping state around a stateless protocol is... • Diffing Immutable Data Structures is fast • http://en.wikipedia.org/wiki/Hash_array_mapped_trie • You only update the path/parts that changed • Browser Compatibility and Normalization • Fix all the things! (that the DOM is horrible at)
- 9. Heuristics • Accepted rules to allow for O(N) diffing computation • Versus O(N3) • Keys • Seriously, a lack of keys will cause crazy behavior • Without keys, React won’t be able to know about dynamic DOM updates • Single Node • Components must return a single node • Can return any number of nodes within that • Use parentheses (just do it) • Component Levels • Components should never move vertically
- 10. JSX • Completely Optional • XML-usg syntactic sugar • Easier to reason about for engineers • Easier for designers to contribute • Give it a try
- 11. JSX
- 12. JSX
- 13. Gotchas • Including JSX Transformer • <script type=“text/jsx”></script> • <div style={wtf}></div> • <div className={wtf}></div> • ClassSet makes up for this annoyance • Components must return a single element • Auto-binding of this and closures • KEYS • Seriously, these are crucial • Must be unique
- 14. Why Use It? • Portable/Agnostic • Performance • Maintenance • Comprehensible • Testable
- 15. Demo
- 17. Resources • YouTubez • David Nolen: Immutability, Interactivity, and JavaScript • Tom Occhino and Jordan Walke: Introduction to ReactJS • Pete Hunt: Rethinking Best Practices • Steven Luscher: Developing User Interfaces with ReactJS • Just look up ‘ReactJS’ on YouTube, there are some other great videos • Links • ReactJS • ReactJS.NET • Flux • Virtual DOM
- 18. Flux
Editor's Notes
- JavaScript Library Created By Facebook =>It was open sourced in mid-2013 =>Currently at version 0.11.1 Smart View Engine =>Smart View Engine: Think “controller-views”, I know, that sounds awfully coupled, doesn’t it? What it is NOT =>Comparing React to Angular or Ember is like comparing apples and fruit markets (thanks reddit) *When I say large applications, I mean really large applications with rich user experiences, not just LOB applications that need some small JS widgets here and there. ? Who is currently maintaining a seriously large application with a metric shit ton of JavaScript? You may want to consider React.
- React Renders your UI React presents what your View should look like at a given point in time React Responds to User Interactions =>And responds to user interactions. Think of it as a more declarative jQuery. =>Prevents unwanted state Reduces Complexity =>React encourages you to write Components with SRP in mind, versus writing a bunch of spaghetti JavaScript and trying to mitigate changes in data over time. Performance =>React has a ton of performance benefits that you get for free, I’ll discuss these in depth a bit later
- There are a lot of client-side JS frameworks… a lot Two Way Data Binding Two way data-binding isn’t always a bad thing, it has its place, like everything else But JavaScript is based on the von Neumann model of computing, meaning data only flows in one direction You assign values right to left. Building a two-way data binding abstraction fights this aspect of the language It also makes it more difficult to reason about the program, since data flies in and out modules in multiple directions And performance is hard to think about with regard to cascading updates When it works, 2-way data binding is great, when it doesn’t, it’s difficult to deal with. React does have two way data binding (of sorts) if you want it Templating You’re handcuffed by whatever your Template Engine of choice provides to you With React, you have the full arsenal of JS at your disposal to decide how your data should be rendered Templates aren’t really separating concerns, but technologies You’re already on the client, you’re in the View You write JavaScript, or use JS frameworks to manipulate HTML, so you’re writing JS-based display logic, hence, it’s a View/Display concern React favors and accepts this level of coupling because it’s inherently cohesive for your JS and Display Logic to live together After all, JS was written to work with the browser. You know, that thing that presents your View… Frameworks Because React is a library, and it is written to be truly agnostic, you can use it with any existing framework (or your own implementation) All it cares about is rendering data Many frameworks contain specialized concepts that engineers have to learn and deal with in order to make their underlying implementation work. There are a lot of leaky abstractions in these frameworks React has one leaky abstraction
- ***These aren’t esoteric, as they are nothing new in terms of programming concepts*** Components Think of the events as a more declarative jQuery If you find yourself heaping too much responsibility into a Component, create a new one Should model the hierarchy of your data Props Simply put, props are the data you want to render, typically passed in from the server or an external service Should be treated as an immutable data structure State State should also be thought of as immutable, but state will change through calls to this.setState() You pass in what the new state of the object should be, and your component will re-render itself with the new state/data Sounds horribly inefficient, right? Virtual DOM
- Virtual DOM This is a new concept, but you don’t really have to worry about it, learn about it, or know anything about it outside of a basic understanding of what it’s doing for you. And honestly, if you don’t know what the DOM is, and can’t discern what a virtual DOM is, maybe you shouldn’t be doing this…
- You need to include the JSXTransformer.js along with the react.js file in order to develop with JSX text/jsx for JSX based script Should compile to JS for deployment, see, React Compiler Inline styles are bad anyway, and you shouldn’t use them, but it’s not a horrible hindrance to use objects for style className is a minor inconvenience, but no big deal, classSet is an awesome add on Components should only ever return a single element (have to wrap everything) Keys are super important. They’re the way that dynamic elements are differentiated between renders, so when you’re diffing between renders and you have two collections, how would your collection determine where to place the new item(s)?