import { Head } from 'mdx-deck' import { Appear } from 'mdx-deck'
import 'style-loader!css-loader!codemirror/lib/codemirror.css' import 'style-loader!css-loader!./cm-night-owl.css' import 'style-loader!css-loader!./styles.css' import 'codemirror/mode/javascript/javascript' import 'codemirror/mode/jsx/jsx' import {CodeBlock} from './JS/code-block' import Logger from './JS/logger' import App, { WordList, Form } from './JS/example/App' import MyComponent, {SecondComponent} from './JS/MyComponent' import { Split } from 'mdx-deck/layouts'
export {default as theme} from './theme'
- So, I titled this talk React for Smarties because, while this is intended to be an introduction to React, I think you're all very smart
So I'm going to touch on more advanced concepts and design patterns in addition to the basics
- By the way, I'm Jeremy. I've been a consultant here for about 6 months and I'm loving every day of it
- So, let's get started
- 4. React has had a meteoric rise since it's conception and it keeps getting more and more popular. Job listings, library downloads, and github stars are getting higher and higher every year. I know that many schools including dartmouth are teaching web dev classes in React and many into to programming courses are taught in javascript. There are many reasons for this, but it's pervasivness is undeniable.
In case you're wondering what React *actually* is
- 1. Not really much to say about this. React was initially released by Facebook five years ago and has since taken the web dev community by storm. It's MIT licensed and maintained by React engineers and the community at large
- 2. React makes use of a great markup-like syntax called JSX. Although not required, this is part of the beauty of React code. It's a little hard to explain, so here is an example.
- JSX allows us to pass around html like it's a javascript type and it lets us integrate javascript into html directly
- 3. React is really good at being declarative and being composable. Because of this, components can be put to many novel uses (like handling routing and error handling) and components can be infinitely nested within eachother. Hopefully you'll be able to see this directly throughout this talk
- {{ error }}
<CodeBlock style={{ fontSize: 30 }}>{`errorList ?
-
{errorList.map(error =>
- {error} : // Something else `}
- On the left we have a tiny piece of a template you would see in angular, and on the right some React code.
- Just to explain what's happening, on the left it's saying IF errorList exists, then render this code, which has a FOR loop
- in the React code we're utilizing JSX to map through the errorList and render a <li> tag for every member of the list
- I find this to be more declarative than the angular version, because it describes the flow, more than it does explicitly say what we want to happen.
- On the other hand I find the angular template syntax to be quite ugly. I feel like "Thanks Google for letting me write a for loop and an if statement... Just let me write my own code!"
- CHANGE SLIDE
- Anyways, just to drive the point home about react being declarative, I want to show you some realistic React code
- This piece of React code demonstrates what the coder wants the look to how like. The app is wrapped in a component that provides data, and has a few identifiable pieces, like a Nav bar, a Dashboard and a footer
A quick note about the nature of Javascript
- Before I go on, I want to talk about the nature of Javascript as this language feature is essential to React development
- CLICK SLIDE
- In Javascript a function can return another function. Furthermore, the function that gets returned can access the arguments of the function that created it, and will have memory of those arguments
- Because of this, the following code is legal in React. You have a function which takes a number, that returns a function that also takes a number. That inner function will alert a mesage on the screen.
- CLICK SLIDE
- can someone tell me what will happen when I click this button?
- CLICK SLIDE
- Because of this, javascript allows for really cool functional programming like this curry function, which is a function, that returns a function, and in turn returns another function and is used often in functional programming.
- this isn't especially important, but I wanted to include it just because I think it's cool
Also Props
- Alright, so the most important concept to know to actually build something in react is....
- CLICK SLIDE
- COMPONENTS!!!!! Conceptually, components are like JavaScript functions. They accept arbitrary inputs (called “props”) which are also important
- CLICK SLIDE
- and return a special kind of markup called JSX which is a powerful tool, combining HTML and Javascript to describe what should show up on a page
- These components will often look like these. They are Functions which accept props (or properties), and return a mix of HTML and Javascript
- There are actually two types of components in React
- CLICK SLIDE
- Functional and Stateful
- CLICK SLIDE
- on the Left we have a functional component, much like the few components we've already seen defined in this talk, they look like regular fat arrow Javascript functions
- on the right we have a component which uses the syntax of an ES6 class. this component is more involved because it can have state, it has lifecycle methods which are functions that execute when the component is rendered, updates, or taken off the page. Furthermore we can define our own methods that manipulate the state of the component
Props
- lets talk about props. What are they, how do they work, and why should I care?!?!
- I'll tell you... that's a bit aggressive, but I'll tell you
- Props are arbitrary arguments that can be passed to Components. They can be any data type including primitives, objects, functions, or even components
- Props are pieces of data that can only be passed one way, from parent to child
- CLICK SLIDE
- Right here we have a stateful component, much like the one we saw before, we'll focus at the bottom
- the WordList and Form components are being passed all the state and the methods (which manipulate the state) that we defined above. this is passing down props in action
- In these components these props are being defined pulled out in the arguments section (because we know that these functions are being passed props as an object, we can destructure the keys from those objects).
- those props are being used in the components
- Now let's see this app in action
<CodeBlock style={{ fontSize: 50 }}>{<App />
}
- Well, I didn't tell you that it would be pretty.
- Either way, this a fully functioning app that utilizes a stateful component to define the app state and pass down methods
- it also uses functional components with passed down props to define the UI precisely
<CodeBlock style={{ marginTop: 26, fontSize: 26, fontStyle: 'oblique' }} options={{ lineNumbers: true }}>{<h1>My code goes here!</h1>
}
- Let's go over nested components a little bit more
- On the left we have some code that will be rendered. The CodeBlock component is being passed a couple props, like a styles object and an options object.
- On the right we can see that the result of this code is a formatted code block. It has the syntax highlighting of something we would see in an IDE, but it's a little big, and it has a line number attached
- CLICK SLIDE
- So you may be wondering what the actual implimentation of CodeBlock looks like
- It really is a wrapped around another React Component called CodeMirror, which actually comes from a third party library.
- If you're wondering what *this* component looks like, we can just go in the source code and see
Higher-Order Components
- So that was a really quick overview of what I would consider the "basics" of React to be, and now we're getting into questions of reausability and readability
- you might be finding yourself repeating code often if your're using only the basics, for example you might be using the same styles over and over again, or you might be repeatedly calling a certain endpoint when a component renders
- luckily some *bearded hipsters* in san francisco found a solution, call High Order Components or HOCS
- CLICK SLIDE
- Essentially, a higher-order component is a function that takes a component and returns a new component.
- They are reusable and stackable, you can wrap a HOC in a HOC like you see here
- Personally I opt to use the 3rd option because I find it to be nice and declarative
<CodeBlock style={{ fontSize: 25 }}>{function someHOC(WrappedComponent) { return class extends React.Component { state = { // Do you want your HOC to enhance a component with state? }\n componentDidMount() { // How about a lifecycle method? }\n someMethod = () => // or pass down a method?\n render() { return ( <WrappedComponent extraState={this.state} extraMethod={this.someMethod} {...props} // to pass down props from other composed Components /> ) } } }\n\n const EnhancedComponent = someHOC(BoringComponent)
}
- This is what most HOCs will look like. a function that takes in a React Component as an argument and returns a Component from this
- This is an example of a HOC that adds state to a Component, but HOCs can also add styles, the ability to do routing, and many more things
export default Split
<CodeBlock options={{ lineNumbers: true }} style={{ fontSize: 18 }}>{`const ManufacturerTransfer = ({ user, history, form, // 😡😡😡 THIS IS HEINOUS 😡😡😡 updateState, products, handleChange, handleProductDropdown, handleCheckboxEvent, removeItemFromState, }) =>
- unfortunately there are some potential downfalls to using HOCs
- This is some code that I wrote for a personal project last winter. The component on the right is called ManufacturerTransfer and on the left you can see the four HOCs that I wrapped this component in
- One problem that I brought onto myself is that I passed in 9 props to this component, this is too much and I could have compartmentalized it a little but it still illustrates some problems.
- first of all, we know that those props at the top come from the HOCs on the left, but we don't know which prop comes from which higher order component. This is a problem because the code lacks separation of concerns,
- also, what if two or more of those HOCs pass down a prop of the same name? one of them will get over written.
- Luckily, the bearded hipsters in san francisco have blessed us with a potential solution that can replace HOCs called the render prop
<CodeBlock style={{ fontSize: 31 }}>{`const ProviderComponent = ({ render }) => render({ name: 'Jeremy', adjective: 'favorite', food: 'ramen', })\n <ProviderComponent render={({name, adjective, food}) =>
- Now we have a component that looks somewhat different. Instead of returning some HTML, this component returns the result of a function that gets passed down as prop
- When we put this component to use we need to have a prop on it called render, which is a function that will return something to render
- in this case the render method is called with some data, that is now available in this function
Questions?