ReactJS Code Impact

Editor's Notes

• #4: 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.
• #5: 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
• #6: 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
• #7: ***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
• #8: 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…
• #14: 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)?