This is the first half of a presentation I gave at Squares Conference 2015 where I provided a brief introduction to React JS, then did live coding for 20 minutes to show more of the specifics of usage. Your milage may vary as the live code part was where the bulk of the teaching happened!
10. “We strongly believe that components are the right way to
separate concerns rather than "templates" and "display logic."
We think that markup and the code that generates it are
intimately tied together. Additionally, display logic is often
very complex and using template languages to express it
becomes cumbersome.” – React Docs
11. JSX is optional
var Blog = React.createClass({
render: function() {
return <Post id="123" type="quote">
<Author name="Doug Neiner" />
<PostContent text="..." />
</Post>;
}
});
12. JSX is optional
var Blog = React.createClass({
render: function() {
return React.createElement(Post, {id: "123", type: "quote"},
React.createElement(Author, {name: "Doug Neiner"}),
React.createElement(PostContent, {text: "..."})
);
}
});
13. JSX Gotchas
• Empty elements must include the closing slash: <MyElement />
• class and for attributes are reserved in JavaScript,
so they are written as className and htmlFor in JSX
• The style attribute takes an object literal of key/values not a string
• There are more:
• http://facebook.github.io/react/docs/dom-differences.html
• http://facebook.github.io/react/docs/jsx-gotchas.html
14. Virtual DOM
• Re-render on change vs. mutate
• Render is a description
• Increases predicability
15. Unidirectional Data Flow
• Changes always flow down to via props, never up
• Callbacks and actions will flow up
16. Synthetic event system
• Events are normalized across browsers
• Events are passed into components as props
• Events are automatically delegated
17. At this point, I switched to live code and
showed how to start with a static comp
and turn it into a React component.
No slides for this part, sorry!
React.js is an ultra-fast view layer for modern web applications.
It is a library, not a framework – so it seeks to solve the challenges around the UI layer without encroaching on the rest of your application.
It describes itself as the V in MVC, but for certain use cases, it can be used to power the whole app (Though at LeanKit, it lives strictly as the View layer since we use the Flux architecture pattern via Flux.js).
Notice the part that looks like JavaScript? Notice the part that looks like HTML? Try to forget they are in the same file for a bit. We’ll cover why that is later!
But this is a simple React component that is utilizing three other React components, Post, Author, and PostContent.
Focus on this for now. Just the part that looks like HTML as we try to establish some comparisons based on what you already know about the DOM.
1. React can be visualized as a tree structure similar to DOM. Components that contain other components which in turn may contain other components.
2. React components can be thought of as custom DOM elements, but by the time they hit the actual page they are just plain DOM elements – nothing like custom HTML5 DOM elements.
3. React components can be configured from the outside using their form of attributes called props. Just like you might set a `type` on an input, you can set a prop on a component.
We would never say a <div> owns a child <a>, but in React, components that are responsible for setting the props of other components are called owners.
There are some extra props that you won’t find in HTML, but we won’t get into this much today.
You are probably already pretty good at this…
We have found a pretty close parallel at LeanKit between CSS class names and our components. If you use BEM, OOCSS or SMACSS understanding how to split your UI into discrete and right-sized components should come pretty naturally.
A JavaScript syntax extension that will transpile into pure JS before its loaded into the browser.
Regarding the old approach of keeping HTML and JS separate, Pete Hunt said its not about separation of concerns but rather separation of technologies. The concerns are the same concerns for both the traditional template and the code it pairs with.
This turns into…
… this. And you can skip JSX and just write this, but most folks generally don’t.
The render methods return a description of what the DOM should look like. This is used to construct a Virtual DOM (Also referred to by the React docs as a Mock DOM). Then, when state changes, and the tree is re-rendered, the new Virtual DOM is compared to the old Virtual DOM and the smallest number of changes is produced. Its a common misconception that the new Virtual DOM is always compared to the actual DOM, when it is actual compared to the previous Virtual DOM.
1. This makes your app very easy to reason about. Given the same state and props, your component will render the same way every time.
2. Clicking a button no longer "dismisses the dialog" – It changes a value in state, that when re-rendered, will result in the dialog going away.
3. We think of "render" as "update visuals", but the render method just returns a snapshot of what the DOM *should* look like at that point. If nothing changed, no changes will be made to the page.
1. Changes in a React app flow one direction, from some part of the tree down – never up. Triggers (or actions as they are often called) can bubble up (via callbacks, messaging, or dispatcher), but any resulting change starts in one location and flows down.
2. This makes the app very easy to reason about and very predictable.
1. Events that behave the same across browsers
2. Event handlers are passed into components as props, and might look like how you've been told NOT to do thing – but in reality it wires them up correctly using delegation. You don’t need multiple handlers on the same element as you control the handler in your component.