{{ page.title }}
8 |
11 | {{ content }}
12 |
13 |
14 |
12 | {{ content }}
13 |
14 |
24 |
30 | )
31 |
32 | ReactDOM.render(
25 |
29 | svideo
26 | 27 | 28 |npm run build. If you followed the CSS naming and HTML structure, you should see a nice looking landing page. Also a good time to run npm run test to see if your code is still lint-compliant.
36 |
37 | So, another tooling detour here: I'm getting pretty sick of having to hit the terminal every single time to see run build. Furthermore, build for webpack is pretty slow despite how small our code is. So let's take advantage of webpack's watch feature. This will watch for every time you save rebuild automatically. Additionally it will keep the unchanged bits (like the React library) in memory so it doesn't have to rebuild it every time. Try running webpack --watch in your terminal. It will use the same config we already made. See how much faster it is after running? Let's add a new npm script.
38 |
39 | {% highlight json %}
40 | // in package.json in scripts
41 | "watch": "webpack --watch",
42 | {% endhighlight %}
43 |
44 | Great, right? So, another part that's been bothering me is that it's such a pain to have to re-run standard every time. Either that or you'll get a bunch of errors all at once when you run it before you commit. Luckily we can have webpack run standard each time it compiles. It will then notify you when you have errors.
45 |
46 | Just like we're using the babel-loader to transpile our code, we're going to use the eslint-loader to run standard for us. eslint is what standard uses under the hood, or in other words standard is just a specific configuration of eslint. We're going to lean on this fact and use a config file with the eslint-loader.
47 |
48 | Create a file called .eslintrc.json. That first period is significant. Inside the new file put:
49 |
50 | {% highlight json %}
51 | {
52 | "extends": ["standard", "standard-react"]
53 | }
54 | {% endhighlight %}
55 |
56 | This will configure eslint to check for everything standard has been checking. In addition, since we're already adding a config file, we're adding a few checks specific to React and JSX. Again, these will spare you bugs in the future and they're super helpful. Let's change our webpack config to use our new eslint-loader. eslint will automatically use our .eslintrc.json, regardless is called via the CLI or programmatically via webpack.
57 |
58 | {% highlight javascript %}
59 | // inside module, before loaders
60 | preLoaders: [
61 | {
62 | test: /\.jsx?$/,
63 | loader: "eslint-loader",
64 | exclude: /node_modules/
65 | }
66 | ],
67 | {% endhighlight %}
68 |
69 | Nice! Any time you save now using npm run watch it will both compile your code _and_ lint it. Pretty slick. And it all runs so much faster. We're going to get to how to make your code reloads _even faster_. But first let's keep going with our app.
70 |
71 | Our landing is pretty much done for now. We want to start working on the browse all page, but we need to move onto the router to do that real quick.
72 |
73 | [radium]: http://stack.formidable.com/radium/
--------------------------------------------------------------------------------
/_posts/2016-01-06-jsx.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "JSX"
3 | ---
4 |
5 | We have been writing our React with vanilla JavaScript up until now which frankly few people do. Most people take advantage of JSX which essentially adds HTML/XML-like syntax as a "primitive" type to JavaScript. In reality, what it does it takes the HTML you write for your components and translate them into the same calls we writing just using vanilla JavaScript.
6 |
7 | So why JSX? People usually get pretty grossed out by the HTML in the JavaScript and say it looks like 1998 when we were still writing JavaScript in our HTML. However, I assert that markup in JS is a good thing while JS in markup is a bad thing! Here, we're keeping all the concerns of a component in one place: the markup structure, the event listeners, the state, the state mutators, everything. If the component breaks, we know it broke there. That's really valuable.
8 |
9 | So try it. While the plain JS way isn't too bad, once you start writing JSX I _almost_ guarantee you won't want to go back. Let's convert what we have to JSX.
10 |
11 | Side note: good idea to install a JSX syntax highlighter. If you're using Sublime, I highly recommend the "Babel" package off of Package Control. If you're using VIM, good luck. I've heard people struggle to get it right with VIM.
12 |
13 |
14 | Open MyTitle.js and rename it to MyTitle.jsx. It doesn't actually matter since both are getting run through Babel but it does signify to all who follow that this file __must__ be compiled before being shipped out.
15 |
16 | {% highlight javascript %}
17 | const React = require('react')
18 | const div = React.DOM.div
19 | const h1 = React.DOM.h1
20 |
21 | const MyTitle = React.createClass({
22 | render () {
23 | const style = {color: this.props.color}
24 | return (
25 |
26 |
30 | )
31 | }
32 | })
33 |
34 | module.exports = MyTitle
35 | {% endhighlight %}
36 |
37 | We're using JSX finally! Make sure you're inserting those opening and closing parens around the component. It's just letting JS know you're going to put your expression on the next line (which we want to do for readability.)
38 |
39 | Notice the curly braces surrounding 27 | {this.props.title} 28 |
29 |this.props.title. They're there to let JSX know I want his to be a JS expression. If they weren't there, it would put the string 'this.props.title'. Notice the double curly braces surrounding the style value. The exterior set of curly braces are the same as the one as before: they're letting JSX know you want a JS expression. The interior set of curly braces represent a JavaScript object, meaning you're passing in a object to the style attribute. A little strange to get used to seeing that.
40 |
41 | Lastly, you may notice that I switched to an ES6 style here. This is synonymous with the function syntax; just a bit more terse. Feel free to write it in any syntax that fits your fancy; this is very readable to me but may not be to you. Basically, since it's an arrow function and lacks curly braces, the resulting component is implicitly returned automatically.
42 |
43 | Let's rewrite ClientApp.js. Rename it to ClientApp.jsx.
44 |
45 | {% highlight javascript %}
46 | const React = require('react')
47 | const ReactDOM = require('react-dom')
48 | const MyTitle = require('./MyTitle')
49 |
50 | const MyFirstComponent = () => (
51 |
52 |
56 | )
57 |
58 | ReactDOM.render(My Title
76 |My Title 2
77 | ); 78 | 79 | // will compile 80 | const ValidComponent = () => ( 81 |
82 |
85 | );
86 |
87 | {% endhighlight %}
88 |
89 | Hence why you'll see a lot of wrapping divs in JSX; it's so the whole thing will compile. This is fine if you need to do this; an extra wrapping div does nothing of harm unless you have structurally sensitive CSS. Also notice that if you have just raw text to put into JSX, you can enter it just as if was normal HTML. It's only when you have JS expressions when you need to use the curly braces.
--------------------------------------------------------------------------------
/_posts/2016-01-21-webpack-chunking.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "webpack Chunking and Async Routing"
3 | ---
4 |
5 | So far all of our routing with react-router has synchronous which makes sense. When we detect that a user has requested a route, we already have that route in our bundle.js and we render and serve that to them. The logic follows.
6 |
7 | However, as our app grows and grows, our bundle.js is going to get bigger and bigger in file size. Wouldn't it be better if you were on Search that it served you _just the JavaScript you need for that page and none of the JS for Landing or Details? For example, Search doesn't need the omdb client we brought in: that client can safely just be loaded on the Details page.
8 |
9 | Enter webpack's code splitting ability. It's smart enough to know which files are required by which other files and thus if you choose to use webpack's async loading API (My Title
83 |My Title 2
84 |require.ensure) then webpack will _automatically_ start chunking your JS for. What's more is we don't have to write the glue code that will download the chunks as we need them: webpack just does this for us. All we have to do is identify the modules that can be async by treating them as if they were. Really cool.
10 |
11 | So we're going to treat all of our routes as async and luckily react-router is already instrumented for this for both server and client-side. So let's go make it happen!
12 |
13 | So first we need give a minor tweak to webpack.config.js.
14 |
15 | {% highlight javascript %}
16 | // inside of the output config object
17 | publicPath: '/public/'
18 |
19 | // inside stats
20 | chunks: true
21 | {% endhighlight%}
22 |
23 | First we need to tell webpack where to find all of its bundles instead when it calls back to the server to grab them. We also would like to see some webpack stats now on chunks since we're using them.
24 |
25 | Go to ClientApp
26 |
27 | {% highlight javascript %}
28 | // delete requires for Landing, Search, Details, Route, and IndexRoute
29 |
30 | // after the requires
31 | if (typeof module !== 'undefined' && module.require) {
32 | if (typeof require.ensure === 'undefined') {
33 | require.ensure = require('node-ensure')// shim for node.js
34 | }
35 | }
36 |
37 | // replace myRoutes
38 | const rootRoute = {
39 | component: Layout,
40 | path: '/',
41 | indexRoute: {
42 | getComponent (location, cb) {
43 | require.ensure([], (error) => {
44 | if (error) {
45 | return console.error('ClientApp Landing require.ensure error', error)
46 | }
47 | cb(null, require('./Landing'))
48 | })
49 | }
50 | },
51 | childRoutes: [
52 | {
53 | path: 'search',
54 | getComponent (location, cb) {
55 | require.ensure([], (error) => {
56 | if (error) {
57 | return console.error('ClientApp Search require.ensure error', error)
58 | }
59 | cb(null, require('./Search'))
60 | })
61 | }
62 | },
63 | {
64 | path: 'details/:id',
65 | getComponent (location, cb) {
66 | require.ensure([], (error) => {
67 | if (error) {
68 | return console.error('ClientApp Details require.ensure error', error)
69 | }
70 | cb(null, require('./Details'))
71 | })
72 | }
73 | }
74 | ]
75 | }
76 |
77 | // replace Router and its children
78 | module.exports = MyTitle. At the top of ClientApp.js, put the line var MyTitle = require('./MyTitle'). Let's try to compile that.
14 |
15 | You should have webpack 1.12+ installed (this is untested on 2.0+.) Go to the directory of the project in the terminal and run mkdir public. After that, run webpack js/ClientApp.js public/bundle.js. In your index.html, change the line of <script src="js/ClientApp.js"> to <script src="public/bundle.js">.
16 |
17 | Try your browser again. bundle.js has all the stuff for both files now. Now we can keep components in their own files which is a huge win for organization. But wait, we can use webpack for even greater code by using it to bring in node modules. In index.html, remove the other script tags so _just_ bundle.js is left.
18 |
19 | In ClientApp.js, remove the global comment at the top and add at the top
20 |
21 | {% highlight javascript %}
22 | var React = require('react')
23 | var ReactDOM = require('react-dom')
24 | {% endhighlight %}
25 |
26 | Likewise at the top of MyTitle, add the line var React = require('react'). Run your webpack command again. Try your browser again. Despite only including bundle.js, the whole app works! If you look at webpack, you'll see it's 99% React code and some of yours. Now we can go forth making new files and including new libraries without worrying about if they are being included!
27 |
28 | Let's add build to our npm scripts. Add to scripts in package.json "build": "webpack js/ClientApp.js public/bundle.js",. Run npm run build from your terminal in the project root directory and see if it works. Magic!
29 |
30 | ## Babel
31 |
32 | Babel is an amazing, amazing tool that has fundamentally altered the landscape of JavaScript as we know. Though they didn't invent the idea of transpiling future syntax of JavaScript into current syntax (thanks Traceur,) they did make it so damn _easy_. Couple that with the fact it worked with React's JSX (which we'll talk about in a sec) out of the box and it was a perfect storm the be massively successful. Babel, in short, is amazing and should be something you consider for every project.
33 |
34 | Babel 6 (the latest revision of Babel) took away a tiny bit of that ease of use but in return it became much easier to develop which is important when you're important when you're maintaining a massive project that's very important. In return it requires a bit of config now.
35 |
36 | Create a new file called .babelrc. Inside .babelrc, put:
37 |
38 | {% highlight json %}
39 | {
40 | "presets": ["react", "es2015"]
41 | }
42 | {% endhighlight %}
43 |
44 | Babel has the concept of plugins. Each transformation comes in the form a plugin. However ES6 and React each have a number of transformation and it's a huge pain to include each one. Thus Babel has the concept of presets, or in other words bundles of plugins. In this case, we're including _all_ of the React and ES6 transformations. If this were a production app we would definitely go through and only include the transformations we needed and _not_ all of them. For example, this includes a fairly large library to get ES6 generators working. Few people these days are actually using generators and thus it's better to leave them off if you don't need them. In our case, this is a teaching app so page weight isn't a big deal to us. This will also allow us to start using JSX.
45 |
46 | ## webpack loaders
47 |
48 | So, we could use the Babel CLI to compile our code but we are already using webpack and webpack has a good way to send your code through Babel via its loader mechanism. Loaders are utilities that webpack will pipe input into and accept output out of. You can use loaders to transpile things like CoffeeScript, TypeScript, or PureScript. Webpack loaders can do some other powerful things like allowing you to _include_ CSS, inline images via encoding, and transform SVGs. We're just going to be using the JS transformation abilities for now. Run the command webpack --module-bind 'js=babel' js/ClientApp.js public/bundle.js. Should take a bit longer since it's doing more. Since we're going to be using webpack for a few other things, let's abstract that configuration from inline to a config file. Add a `webpack.config.js` with the following.
49 |
50 | {% highlight javascript %}
51 | const path = require('path')
52 |
53 | module.exports = {
54 | context: __dirname,
55 | entry: './js/ClientApp.js',
56 | output: {
57 | path: path.join(__dirname, '/public'),
58 | filename: 'bundle.js'
59 | },
60 | resolve: {
61 | extensions: ['', '.js', '.jsx', '.json']
62 | },
63 | stats: {
64 | colors: true,
65 | reasons: true,
66 | chunks: false
67 | },
68 | module: {
69 | loaders: [
70 | {
71 | test: /\.jsx?$/,
72 | loader: 'babel-loader'
73 | }
74 | ]
75 | }
76 | }
77 |
78 | {% endhighlight %}
79 |
80 | What you see is essentially a config version of what we were doing with CLI flags. Now it's a bit more resilient and guaranteed consistent. If you run just the command webpack from your project directory you should get the same output. Neat. Go change you npm script to just be "webpack" now. Go try it and make sure it still works. Great! Also make sure all the files you've written are still up to snuff with standard via npm run test. Good? Good. This should get us to a point now where we can talk about JSX.
81 |
--------------------------------------------------------------------------------
/_posts/2016-01-11-react-testing.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Testing React with Mocha, Chai, and Enzyme"
3 | ---
4 |
5 | So now we have a component worth testing so let's do that. We're going to be using the old standbys [Mocha][mocha] and [Chai][chai]. These principles will generally apply to AVA or Jasmine too but I rolled with Mocha due to the fact that I've used it for so long that it's easy for me teach.
6 |
7 | We're also going to be using a testing helper from our friends at Airbnb called [Enzyme][enzyme]. Enzyme is just some helpers to make testing React components easier. You don't have to use it; the React testing utils are great too (and you can use both of them at the same time too.)
8 |
9 | So, first things first. Create a directory called test. In our test environment, we need a few things to happen. We need JSX/ES6 transpilation to happen or our tests will crash on the unfamiliar syntax. We also need a fake DOM for React to interact with which we'll get from a library called [jsdom][jsdom].
10 |
11 | So in your test directory, create another directory called helpers (these files are automatically excluded from being run as tests by Mocha) and create a file called setup.js. In setup.js, put
12 |
13 | {% highlight javascript %}
14 | require('babel-register')
15 | require('babel-polyfill')
16 |
17 | global.document = require('jsdom').jsdom('')
18 | global.window = document.defaultView
19 | global.navigator = window.navigator
20 | {% endhighlight %}
21 |
22 | This little setup is totally lifted from [Kent C. Dodds][kcd]. Thanks Kent.
23 |
24 | Now that we have our environment set up, let's get our tests set up as an npm script. Add the following to your scripts object in your package.json
25 |
26 | {% highlight json %}
27 | "test": "mocha --require test/helpers/setup.js",
28 | {% endhighlight %}
29 |
30 | You can add -R nyan to the end for fun too. This changes the reporter to be the [Nyan Cat][nyan] and I just can't help my self. There are other [reporters][reporters]. The --require part just makes sure that our setup gets run first before our specs too. I tend to leave it off since it doesn't report the tests that do pass and that's so satisfying for me
31 |
32 | Great! Let's start writing some tests. For this workshop we're just going to shove all our tests into one spec but I encourage you to do split them up into different files as appropriately split-up files. Create a new file called App.spec.js. The .spec.js convention is just to let your future self / other coders know that this file corresponds to the whole app. In this case it's not significant what it's called (the naming is significant in other testing frameworks.)
33 |
34 | In your new file, put:
35 |
36 | {% highlight javascript %}
37 | /* eslint-env mocha */
38 | const chai = require('chai')
39 | const { expect } = chai
40 |
41 | describe('svideo
)).to.be.true 65 | }) 66 | }) 67 | {% endhighlight %} 68 | 69 | So now we're pulling in Enzyme and using its shallow-rendering ability. This means it will render everything except its child composite component. In this case, the only composite components are the ShowCards so it won't reach down into the ShowCards to render them; just stubs. This is sufficient to test if the branding is there. A neat trick is to putconsole.log(wrapper.debug()). That will show you what it's dealing with. Let's add another more useful test.
70 |
71 | {% highlight javascript %}
72 | // add two more requires at the top
73 | const ShowCard = require('../js/ShowCard')
74 | const data = require('../public/data')
75 |
76 | // add another test inside the describe
77 | it('should render as many shows as there are data for', () => {
78 | const wrapper = shallow(<script src="js/ClientApp.js"> so we can get some good code separation going. Once done with that, create the js directory and add the ClientApp.js file. In this file, let's put
49 |
50 | {% highlight javascript %}
51 | /* global React ReactDOM */
52 |
53 | var div = React.DOM.div
54 | var h1 = React.DOM.h1
55 |
56 | var MyTitle = React.createClass({
57 | render () {
58 | return (
59 | div(null,
60 | h1(null, 'Check out this component!')
61 | )
62 | )
63 | }
64 | })
65 |
66 | var MyFirstComponent = (
67 | div(null,
68 | React.createElement(MyTitle, null),
69 | React.createElement(MyTitle, null),
70 | React.createElement(MyTitle, null)
71 | )
72 | )
73 |
74 | ReactDOM.render(MyFirstComponent, document.getElementById('app'))
75 |
76 | {% endhighlight %}
77 |
78 | Cool, right!
79 |
80 | `MyTitle` is a `ReactComponent` class. This is a constructor function that, once invoked, is expected to return a JavaScript object with at least a `render` method on it.
81 |
82 | To invoke this constructor and create a new instance of the `MyTitle` component, you have to use the `React.createElement` method. The resulting instance is a `ReactElement`.
83 |
84 | We can use this element the same way we use any other HTML-native tag. This allows us to encapsulate style, behavior, and markup into one neat little package and reuse these components everywhere!
85 |
86 | To sum-up, we're using `createClass` to create the component and then we're using `createElement` to create an _instance_ of that class, resulting in an element that can be used in others components.
87 |
88 |
89 | ## Factories
90 |
91 | This is a bit verbose to write React.createElement so many damn times. Let's use a shortcut.
92 |
93 | {% highlight javascript %}
94 | // replace MyFirstComponent
95 | var MyTitleFact = React.createFactory(MyTitle)
96 |
97 | var MyFirstComponent = (
98 | div(null,
99 | MyTitleFact(null),
100 | MyTitleFact(null),
101 | MyTitleFact(null)
102 | )
103 | )
104 | {% endhighlight %}
105 |
106 | We can use createFactory to side step this. Now we can use our class like we use div. In fact React.createElement('div', null) works the same as React.DOM.div. The one I showed you is just a convenience factory method that React provides for all of the HTML tags.
107 |
108 | ## Props
109 |
110 | Our title component is cute but not super reuseable. Let's make it a bit more flexible by using some props. Props are variables that you pass from the parent to the child but the child cannot modify the props it gets. This simple restriction helps a lot in the future because when bugs arise, you know the child didn't modify the variable because it can't! Let's see how to do it.
111 |
112 | {% highlight javascript %}
113 | /* global React ReactDOM */
114 |
115 | var div = React.DOM.div
116 | var h1 = React.DOM.h1
117 |
118 | var MyTitle = React.createClass({
119 | render () {
120 | return (
121 | div(null,
122 | h1(null, this.props.title)
123 | )
124 | )
125 | }
126 | })
127 |
128 | var MyTitleFact = React.createFactory(MyTitle)
129 |
130 | var MyFirstComponent = (
131 | div(null,
132 | MyTitleFact({title: 'Props are great!'}),
133 | MyTitleFact({title: 'Use props everywhere!'}),
134 | MyTitleFact({title: 'Props are the best!'})
135 | )
136 | )
137 |
138 | ReactDOM.render(MyFirstComponent, document.getElementById('app'))
139 | {% endhighlight %}
140 |
141 | Now we can change the contents of the title. But since we can pass in lots of props, we can widely differing elements of the same class based on what props are passed into the element. Let's take it a step further (and show you how to do inline styles and attributes with React.)
142 |
143 | {% highlight javascript %}
144 | // change MyTitle's inside h1
145 | h1({ style: {color: this.props.color} }, this.props.title)
146 |
147 | // change MyFirstComponent inside div
148 | MyTitleFact({title: 'Props are great!', color: 'rebeccapurple'}),
149 | MyTitleFact({title: 'Use props everywhere!', color: 'mediumaquamarine'}),
150 | MyTitleFact({title: 'Props are the best!', color: 'peru'})
151 | {% endhighlight %}
152 |
153 | Let's stop there and switch our attention a bit to tooling. So far we've been writing React with no compile step which is pretty cool and not something enough do in the course of React. Certain things will just make sense because you know what it complies to. In any case, onward!
154 |
155 |
--------------------------------------------------------------------------------
/_posts/2016-01-19-universal-rendering.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Universal Rendering"
3 | ---
4 |
5 | Universal rendering, or the artist formerly known as isomorphic rendering. The idea here is that you server-side prerender your code so that when it gets down to the client, your browser can __instantly__ show the markup while your app bootstraps in the background. It makes everything feel very instantaneous.
6 |
7 | With just vanilla React, universal rendering is a cinch. Check out the [whole node file from another one of my workshops][es6-react]. It does server-side rendering in just a few lines.
8 |
9 | It's not quite so simple now that we have routing involved. We don't want to have to duplicate all of our routing info that we wrote for react-router. Rather, if possible, we just want to reuse the routes we already built for react-router. So let's do that (with some refactoring.)
10 |
11 | ## Move shows to redux
12 |
13 | We're passing shows everywhere. In order to simplify our app a lot by not having to worry about passing it in, let's make all the shows-based data just come from redux.
14 |
15 | Go to Store.jsx
16 |
17 | {% highlight javascript %}
18 | // another require
19 | const data = require('../public/data')
20 |
21 | // change initial state
22 | const initialState = {
23 | searchTerm: '',
24 | shows: data.shows
25 | }
26 |
27 | // add to mapStateToProps
28 | const mapStateToProps = (state) => ({ searchTerm: state.searchTerm, shows: data.shows })
29 | {% endhighlight %}
30 |
31 | Cool. Now these shows will available to any connected components. Let's go fix Details first.
32 |
33 | {% highlight javascript %}
34 | // bring in connector
35 | const Store = require('./Store')
36 | const { connector } = Store
37 |
38 | // pull show from redux
39 | const { title, description, year, poster, trailer } = this.props.shows[this.props.params.id]
40 |
41 | // add proptype
42 | shows: React.PropTypes.arrayOf(React.PropTypes.object)
43 |
44 | // connect component
45 | module.exports = connector(Details)
46 | {% endhighlight %}
47 |
48 | This should fix Details. Let's fix Search.
49 |
50 | {% highlight javascript %}
51 | // change the statement to map and filter
52 | {this.props.shows
53 |
54 | // overwrite the route proptype
55 | shows: React.PropTypes.arrayOf(React.PropTypes.object),
56 | {% endhighlight %}
57 |
58 | Just needed pull shows from a different part of the params. Not much else to change here. Now (while your tests and lint are failing at the moment) the app should still work but the shows are coming from redux. Let's go clean up ClientApp.jsx
59 |
60 | {% highlight javascript %}
61 | // remove data.json require
62 |
63 | // remove shows attribute from Search
64 |
65 | // remove assignShow onEnter from Details
66 |
67 | // remove assignShow method and constructor from App
68 | {% endhighlight %}
69 |
70 | Feels good to delete code. We successfully simplified our app a lot by moving that to redux. And now it will simplify us moving to render universally. Let's fix our test too.
71 |
72 | {% highlight javascript %}
73 | // change the Store init test's expect statement
74 | expect(state).to.deep.equal({ searchTerm: '', shows: data.shows })
75 | {% endhighlight %}
76 |
77 | All tests should pass now. Now we have a few more things to refactor before we can universally render successfully.
78 |
79 | ## Split out BrowserEntry.jsx
80 |
81 | The big key with universal rendering is being careful about referencing window and document as those aren't available in node environments. That isn't to say you can't interact with them: you just have to do if (window) { /* do stuff with window*/ }. Part of that means we need to split out the rendering of ClientApp from the declaration of the component. Remove the ReactDOM stuff from ClientApp, create a new called BrowserLanding.jsx and put this in there:
82 |
83 | {% highlight javascript %}
84 | const React = require('react')
85 | const ReactDOM = require('react-dom')
86 | const App = require('./ClientApp')
87 |
88 | ReactDOM.render(localhost:5050/#/search it's just going to be localhost:5050/search which we can do since we're doing server-side rendering and can control the routes.
92 |
93 | Go back to ClientApp.jsx
94 |
95 | {% highlight javascript %}
96 | // delete hashHistory from ReactRouter destructuring, add browserHistory
97 | const { Router, Route, IndexRoute, browserHistory } = ReactRouter
98 |
99 | // delete data.json require
100 |
101 | // change attribute of <%= body %>
144 | {% endhighlight %}
145 |
146 | Just adding that body template tag will allow to render our React string directly in there. Pretty cool.
147 |
148 | ## Writing the Server
149 |
150 | This is a lot to take in at once but we have to write the whole app at once. Reason being is that you need it _all_ to be able to run the server. So let's write it first and then deconstruct it.
151 |
152 | {% highlight javascript %}
153 | require('babel-register')
154 |
155 | const express = require('express')
156 | const React = require('react')
157 | const ReactDOMServer = require('react-dom/server')
158 | const ReactRouter = require('react-router')
159 | const match = ReactRouter.match
160 | const RouterContext = ReactRouter.RouterContext
161 | const ReactRedux = require('react-redux')
162 | const Provider = ReactRedux.Provider
163 | const Store = require('./js/Store.jsx')
164 | const store = Store.store
165 | const _ = require('lodash')
166 | const fs = require('fs')
167 | const port = 5050
168 | const baseTemplate = fs.readFileSync('./index.html')
169 | const template = _.template(baseTemplate)
170 | const ClientApp = require('./js/ClientApp.jsx')
171 | const routes = ClientApp.Routes
172 |
173 | const app = express()
174 |
175 | app.use('/public', express.static('./public'))
176 |
177 | app.use((req, res) => {
178 | match({ routes: routes(), location: req.url }, (error, redirectLocation, renderProps) => {
179 | if (error) {
180 | res.status(500).send(error.message)
181 | } else if (redirectLocation) {
182 | res.redirect(302, redirectLocation.pathname + redirectLocation.search)
183 | } else if (renderProps) {
184 | const body = ReactDOMServer.renderToString(
185 | React.createElement(Provider, {store},
186 | React.createElement(RouterContext, renderProps)
187 | )
188 | )
189 | res.status(200).send(template({body}))
190 | } else {
191 | res.status(404).send('Not found')
192 | }
193 | })
194 | })
195 |
196 | console.log('listening on ' + port)
197 | app.listen(port)
198 | {% endhighlight %}
199 |
200 | So we require a bunch of stuff and build a basic Express server. From there we're going to use react-router's match function which is what react-router uses internally to match routes. We pass that route to match as well as the URL. From there, we first check for 500s, then for 300s, and then if there was a matched route. If none of those are matched, then we throw off a 404.
201 |
202 | Once a route is matched, we use ReactDOMServer to render our app out to a string (instead of to the DOM.) Once we have that string, we use [lodash][lodash] to template our rendered string into the index.html markup. And that's it! You're universally rendering!
203 |
204 | [es6-react]: https://github.com/btholt/es6-react-pres/blob/master/completed/app.js
205 | [lodash]: https://lodash.com/docs#template
--------------------------------------------------------------------------------
/_posts/2016-01-16-redux.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "redux"
3 | ---
4 |
5 | The next thing we want to do with our app is make the front page's search work so that when you type in a search query and hit enter it will automatically have searched for that on the Search page. Right now you have all the necessary tools to do that via state. You could just push the query term up to the ClientApp level and then pass that down to the Search and you'd be done. And that's probably the way you _should_ do it given how small our app is.
6 |
7 | But when these demo apps all the fun is in over engineering it and that's precisely what we're going to do: we're going to add redux. redux is a _fantastic_ tool and a cool blending of the ideas of Facebook's [Flux][flux] and the [Elm][elm] architecture. If you're going to use a Flux-like architecture in your app, make it redux.
8 |
9 | So what is redux? [Redux is a predictable state container for JavaScript apps.][redux] The best part about it while the concept is at first hard, I'd argue it's also very simple and elegant. redux is great because it will run both client and server side, it's easy to test, and easy to debug. While redux does not __not__ follow the Flux pattern, you can easily see the similarities and once you've done one the other isn't hard to adapt to.
10 |
11 | With redux you a single store which stores your entire app state in a single tree. This is not like Flux where you'll have many stores for many different parts of your app; all data lives in a single store. You cannot directly modify the tree of data stored in this tree by typical assignment (ie tree.prop = 'foo' doesn't work.) Rather, every time you want to modify the tree, you emit an __action__. Your action then kicks off what's called a __reducer__. A reducer is a special function that take a tree and parameter(s) and returns a new tree after applying whatever transformations it deems fit. The way it gets away with just one store is when you need more data you just add more branches to your data tree. Like React? You only have one tree of components and when you need more you just add more nodes (branches) to your components.
12 |
13 | So let's do the most basic addition of redux to our app and convert the Search to use redux. Again, this is using a sledgehammer to solve a tiny nail problem: huge overkill.
14 |
15 | Create Store.jsx. Because our use case is so small, I'm going to shove all our concerns in here. You should separate these out. But not today!
16 |
17 | {% highlight javascript %}
18 | const redux = require('redux')
19 | const reactRedux = require('react-redux')
20 |
21 | const SET_SEARCH_TERM = 'setSearchTerm'
22 |
23 | const reducer = (state = {searchTerm: ''}, action) => {
24 | switch (action.type) {
25 | case SET_SEARCH_TERM:
26 | const newState = {}
27 | Object.assign(newState, state, {searchTerm: action.value})
28 | return newState
29 | default:
30 | return state
31 | }
32 | }
33 |
34 | const store = redux.createStore(reducer)
35 |
36 | const mapStateToProps = (state) => ({ searchTerm: state.searchTerm })
37 | const mapDispatchToProps = (dispatch) => {
38 | return {
39 | setSearchTerm: (term) => {
40 | dispatch({type: SET_SEARCH_TERM, value: term})
41 | }
42 | }
43 | }
44 |
45 | const connector = reactRedux.connect(mapStateToProps, mapDispatchToProps)
46 |
47 | module.exports = { connector, store }
48 | {% endhighlight %}
49 |
50 | Here we're doing everything to bootstrap a redux store. You can see our root reducer function there. With the root reducer, you'll take in an action and then using a switch statement on the action type, you'll delegate that action to another reducer. If necessary, that reducer can delegate to yet another reducer and so on (I haven't had a compelling reason to do that yet.) Right now we don't have a reason to do so that we're just doing everything in the root reducer. You could change the body of the case SET_SEARCH_TERM: to be another reducer function.
51 |
52 | Then to create a new store you just give redux the root reducer and it's created! Cool!
53 |
54 | From there we're going to create a connector. react-redux is a library that provides some simple helpers to connect your redux store to your React app. Everything that react-redux does for you you can fairly easily do for yourself. For that matter, redux itself is a pretty simple library that would possible to write yourself (unlike React; good luck with that!) We're creating a mapStateToProps and a mapDispatchProps to props which are just helpers that will hand your pertinent components with the methods and state they'll need to be able to display it. Now whatever components your wrap with connector will have these bits of state and action creators available to them. We'll see how that works in a sec.
55 |
56 | Let's do some connecting with ClientApp.jsx
57 |
58 | {% highlight javascript %}
59 | // more requires
60 | const Store = require('./Store')
61 | const { store } = Store
62 | const reactRedux = require('react-redux')
63 | const { Provider } = reactRedux
64 |
65 | // change the ReactDOM render call
66 | ReactDOM.render(
67 | (
68 | Provider component makes our store and dispatches available where-ever we wrap components with connector calls, hence why it's necessary to wrap the whole app. Good news is once you do this it magically just works thought out your whole app. You'll only have to use svideo
17 | 18 |
35 |
36 |
39 |
45 | )
46 | }
47 | }
48 |
49 | module.exports = Search
50 | {% endhighlight %}
51 |
52 | {% highlight javascript %}
53 | const React = require('react')
54 | const ShowCard = require('./ShowCard')
55 | const data = require('../public/data')
56 |
57 | const Search = React.createClass({
58 | render () {
59 | return (
60 | svideo
37 | 38 |
40 | {data.shows.map((show, index) => (
41 |
44 |
61 |
62 |
65 |
71 | )
72 | }
73 | })
74 |
75 | module.exports = Search
76 | {% endhighlight %}
77 |
78 | They each have their advantages that I won't discuss at length. I'm going to be using the ES6 one from here on out so I suggest you do that (or else you'll have to translate the examples.) And you can mix-and-match the different syntaxes too.
79 |
80 | After switching to this syntax, your code should still work, but now we can hook into other features that React components have. Namely we're going to add state. Let's do that now.
81 |
82 | {% highlight javascript %}
83 | class Search extends React.Component {
84 | constructor (props) {
85 | super(props)
86 |
87 | this.state = {
88 | searchTerm: 'this is the default searchTerm'
89 | }
90 | }
91 | render () {
92 | return (
93 | svideo
63 | 64 |
66 | {data.shows.map((show, index) => (
67 |
68 | ))}
69 |
70 |
94 |
95 |
98 |
104 | )
105 | }
106 | }
107 | {% endhighlight %}
108 |
109 | Notice the constructor accepts props and passes that up to React via {this.state.searchTerm}
96 | 97 |
99 | {data.shows.map((show, index) => (
100 |
101 | ))}
102 |
103 | super(props). A necessary evil of boilerplate, I'm afraid. Anytime you have initial state of any sort you need to put that line in. Luckily if you forget, React has a friendly runtime error message to remind you.
110 |
111 | I replaced the brand momentarily so you can see the see the searchTerm change. You should see whatever you made the initial state for searchTerm show up as the brand. Neat, right? Alright, let's make it mutable now. Change the input in the header to be this:
112 |
113 | {% highlight javascript %}
114 |
115 | {% endhighlight %}
116 |
117 | Cool! Now your input should have the initial state of your searchTerm. Now try and type and/or delete anything. You can't! You broke the Internet! Just kidding. But to understand why this weird bug is happening you have to understand how React handles keypresses. Your state object on your component states that the value of searchTerm is 'this is the default searchTerm'. When a keypress happens, React kicks off a re-render. Since nothing modified the value of searchTerm, it's still the same string and thus it re-renders the same string there. Your state object is the source of truth. So let's make the value of searchTerm bound to the value of the input.
118 |
119 | {% highlight javascript %}
120 | class Search extends React.Component {
121 | constructor (props) {
122 | super(props)
123 |
124 | this.state = {
125 | searchTerm: 'this is the default searchTerm'
126 | }
127 |
128 | this.handleSearchTermChange = this.handleSearchTermChange.bind(this)
129 | }
130 | handleSearchTermChange (event) {
131 | this.setState({ searchTerm: event.target.value })
132 | }
133 | render () {
134 | return (
135 |
136 |
137 |
140 |
146 | )
147 | }
148 | }
149 | {% endhighlight %}
150 |
151 | Now try typing in the input. As you see, the title is now reflective of whatever you type in the search input. So let's chat about what we did here. We made an event listener that handles the change events that the input throws off when it has a keypress. That event listener accepts an event that's technically a React synthetic event but its API looks just like a normal DOM event. In the event listener, we call {this.state.searchTerm}
138 | 139 |
141 | {data.shows.map((show, index) => (
142 |
143 | ))}
144 |
145 | this.setState, a method that allows you to mutate the state and then lets React re-render. If you don't call setState and instead mutate this.state yourself, React isn't privy to the fact the fact that you're changing stuff and thus doesn't know to re-render. In other words, never modify this.state directly and always just use setState. setState works like Object.assign in that it will do a merge of your objects (it's a shallow merge and not a deep merge) so you're free to just modify the keys you need to. Finally, in the constructor we added a line to bind the correct context of the event listener since we need to ensure that handleSearchTermChange is always called with the correct context.
152 |
153 | So go back now and change the brand to the correct title.
154 |
155 | Let's make the search actually _do_ something now. Since now we have our state being tracked, let's use it do a real time search on our titles.
156 |
157 | {% highlight javascript %}
158 |
159 | {data.shows
160 | .filter((show) => `${show.title} ${show.description}`.toUpperCase().indexOf(this.state.searchTerm.toUpperCase()) >= 0)
161 | .map((show, index) => (
162 |
165 | {% endhighlight %}
166 |
167 | This is a little clever but let's dissect the new filter line we added. We're looking at both the title and description lines to search on and using the indexOf method from strings to see if the searchTerm exists within the description or title. We use toUpperCase on both to make it case agnostic. And the filter method on arrays just filters out items in an array that the method returns false on. Now try typing in your searchBox. You should see it filter as you type. We could make this more efficient but I'll leave that to you in your own time.
168 |
--------------------------------------------------------------------------------
/_posts/2016-01-14-react-marshall-data.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Data in React"
3 | ---
4 |
5 | So now we want to add a third page: a page where we can watch the trailer. This is going to be an application of what we know already.
6 |
7 | Create a new file in js/ called Details.jsx. In Details put:
8 |
9 | {% highlight javascript %}
10 | const React = require('react')
11 |
12 | class Details extends React.Component {
13 | render () {
14 | return (
15 |
16 |
18 | )
19 | }
20 | }
21 |
22 | module.exports = Details
23 | {% endhighlight %}
24 |
25 | In ClientApp.jsx, put your new route:
26 |
27 | {% highlight javascript %}
28 | // require your new route
29 | const Details = require('./Details')
30 |
31 | // add as last route in the nested routes
32 | lolhi
17 |[stuff]/index.html#/details/1. You should see your new component here.
36 |
37 | Let's show you a neat debugging tip I totally stole from [Ryan Florence][ryflo]. replace that h1 with this:
38 |
39 | {% highlight javascript %}
40 | // instead of the h1 in render
41 |
42 | {JSON.stringify(this.props.params, null, 4)}
43 |
129 |
130 |
132 |
142 | )
143 | }
144 | }
145 | {% endhighlight %}
146 |
147 | Now you should have some nice looking UI.
148 |
149 | Well, now we have a header in two places. Let's abstract that in a component and use that in both places. Create a new file called Header.jsx and put this in there:
150 |
151 | {% highlight javascript %}
152 | const React = require('react')
153 | const ReactRouter = require('react-router')
154 | const { Link } = ReactRouter
155 |
156 | class Header extends React.Component {
157 | render () {
158 | return (
159 | svideo
131 |
133 | 
136 |
138 | {title}
134 |({year})
135 |
136 | {description}
137 |
139 |
140 |
141 | 161 | 162 | svideo 163 | 164 |
165 |188 | 189 | Back 190 | 191 |
192 | {% endhighlight %} 193 | 194 | So let's integrate this to Search. But it's not so simple since on Search we want the header to have a search input and on Details we want a back button. So let's see how to do that. In Header.jsx put: 195 | 196 | {% highlight javascript %} 197 | const React = require('react') 198 | const ReactRouter = require('react-router') 199 | const { Link } = ReactRouter 200 | 201 | class Header extends React.Component { 202 | render () { 203 | let utilSpace 204 | if (this.props.showSearch) { 205 | utilSpace = 206 | } else { 207 | utilSpace = ( 208 |209 | 210 | Back 211 | 212 |
213 | ) 214 | } 215 | return ( 216 |218 | 219 | svideo 220 | 221 |
222 | {utilSpace} 223 |
260 | 
261 |
267 |
268 | )
269 | {% endhighlight %}
270 |
271 | [ryflo]: https://twitter.com/ryanflorence
272 |
--------------------------------------------------------------------------------
/_posts/2016-01-09-react-props.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "React: Props"
3 | ---
4 |
5 | Let's start making our search page. Replace JSX HTML in Search with
6 |
7 | {% highlight javascript %}
8 |
261 |
262 |
266 | {props.title}
263 |({props.year})
264 |{props.description}
265 |
9 | {data}
10 |
11 | {% endhighlight %}
12 |
13 | You should see it say "House of Cards" at the top of the page. When you use curly braces in JSX, you're telling JSX you want it run a JavaScript expression and then display whatever it returns. If you take away those curly braces (try it) you'll see it literally displays "data.shows[0].title" as a string. So that's a neat tool to have; let's take it a step further and display all of the titles as their own components.
14 |
15 | As you may remember, JSX is transpiling your JSX-HTML to function calls. As such, you may be able to imagine that a bunch of sibling components are just an array of components. Since they're just normal ol' JavaScript arrays, we can use some functional-programming-fu to transform data into components.
16 |
17 | {% highlight javascript %}
18 | const React = require('react')
19 | const data = require('../public/data')
20 | const Search = () => (
21 |
22 | {data.shows.map((show) => (
23 |
26 | )
27 |
28 | module.exports = Search
29 | {% endhighlight %}
30 |
31 | You should now see all of the titles in a nice scrollable list. This is the ng-repeat/#each of React: plain ol' JavaScript map. This is one of the reasons I _love_ React: for the most part best practices of React are just JavaScript best practices. There's very little DSL to learn. Cool! Let's flesh out how our search results are going to look.
32 |
33 | {% highlight javascript %}
34 | const React = require('react')
35 | const data = require('../public/data')
36 | const Search = () => (
37 | {show.title}
24 | ))} 25 |
38 |
51 | )
52 |
53 | module.exports = Search
54 | {% endhighlight %}
55 |
56 | Try saving and re-rendering. You should see some nice cards for the shows. Notice that we can use those fancy curly braces to insert JavaScript expressions into HTML attribute too. Neat.
57 |
58 | However we can reorganize this a bit better: the Show component can be broken out into its own component. Let's do that. Make a file called ShowCard.jsx and put this in there:
59 |
60 | {% highlight javascript %}
61 | const React = require('react')
62 |
63 | const ShowCard = (props) => (
64 |
39 | {data.shows.map((show) => (
40 |
50 |
41 | 
42 |
48 | ))}
49 |
42 |
43 |
47 | {show.title}
44 |({show.year})
45 |{show.description}
46 |
65 | 
66 |
72 | )
73 |
74 | module.exports = ShowCard
75 | {% endhighlight %}
76 |
77 | Notice we're using this strange props object being passed in as a parameter to the ShowCard component. This is what we are going to be receiving from our parents. In this case, an individual ShowCard needs to receive all the necessary data from its parent to be able to display it.
78 |
79 | This is a good time to discuss the philosophy that's sort of tough to get used to with React coding. We typically think of user interfaces as entities that change over a span of actions and events. Think of a jQuery UI you have made. Imagine making a drop down. You would have to write the code for a user clicking it to opening the drop down to the user clicking an item in the drop down. It's a progression of time, events, and interactions. Imagine if there was a bug with that final interaction. You now have to work out in your head the sequence of events to get it to that same state that the bug occurs in to able to fix it. This is second nature to many of us since we have done it so many times.
80 |
81 | React takes a fundamentally different approach but it takes some retraining of your brain. However I argue this approach is superior due to it being much easier to reason about, making it more readable for newcomers to the code and much more debuggable. In React, you think of your UI as snapshots. You do not think of it as a progression of time and events; rather, you look at the UI as how is it going to look given a set of parameters. That's all it is. Given a set of parameters, how does this UI look? Using the drop down example, you think of the drop down in its various states: an open state, a closed state, and an event that triggers when you click the item. You represent these varying states using props and state (we'll get to state in a bit.) Given a certain set of props, the UI always looks this way. This will become more concrete as we go on.
82 |
83 | This brings me to my next point: when coding React, assume you have all the data you need coming in via props and then figure out later how to get it there. That will make it much easier. Just assume it all works and then later go make it work.
84 |
85 | And these principles? Not invented by React. These are battle-tested ideas that stem a lot from functional programming. There's a lot of good computer science going on here, whether or not we use React to apply these concepts.
86 |
87 | Okay, great, let's go to Search and drop in our new component.
88 |
89 | {% highlight javascript %}
90 | const React = require('react')
91 | const ShowCard = require('./ShowCard')
92 | const data = require('../public/data')
93 |
94 | const Search = () => (
95 |
66 |
67 |
71 | {props.show.title}
68 |({props.show.year})
69 |{props.show.description}
70 |
96 |
102 | )
103 |
104 | module.exports = Search
105 | {% endhighlight %}
106 |
107 | Much like you give an HTML tag an attribute is how you give props to children components in React. Here we're passing down an object to our child component to make it available to the ShowCard via props. Neat, right? Save it and reload the page. standard is going to give you a bunch of complaints but we're going to address that momentarily. You should see the same UI.
108 |
109 | We give it a key so React can internally keep track of which component is which. We give it an id to refer to later.
110 |
111 | So let's fix our standard errors now. standard-react dictates that all props have a propType. React has a features that allows you to set propTypes which it then validates at runtime. This ends up being great for debugging because React now knows what sort of props it should be getting so it can give you a meaningful error messages. So let's go fix the errors.
112 |
113 | In ShowCard, go add this just below the declaration of the ShowCard function:
114 |
115 | {% highlight javascript %}
116 | // below ShowCard
117 | ShowCard.propTypes = {
118 | show: React.PropTypes.object.isRequired
119 | }
120 | {% endhighlight %}
121 |
122 | Now React knows to expect that show is both an object _and_ required for the ShowCard to work. If the prop is optional (which is fine if it is indeed optional) then leave off the isRequired part.
123 |
124 | We can make this a little neater via the ES6/JSX spread operator. Let's try that. Change Search's ShowCard from
97 | {data.shows.map((show, index) => (
98 |
101 |
131 |
132 |
138 | )
139 |
140 | ShowCard.propTypes = {
141 | year: React.PropTypes.string.isRequired,
142 | poster: React.PropTypes.string.isRequired,
143 | description: React.PropTypes.string.isRequired,
144 | title: React.PropTypes.string.isRequired,
145 | id: React.PropTypes.number.isRequired
146 | }
147 |
148 | module.exports = ShowCard
149 | {% endhighlight %}
150 |
151 | We've now made our code a bit cleaner since we don't have to props.show... ad nauseam. We've also made it so React can check each individual property that we need; this will save us bugs in the future.
152 |
153 | ## React Router Layout
154 |
155 | Now, we have a common layout that we want to maintain between all of our pages. This is a common problem: you make a nice looking nav bar and background that you intend to share amongst multiple pages. We could make a nav component and share that but we can take it a step further (right now we're just going to share the background div.) We're going to use nested routes and what's called an IndexRoute. A nested route allows you to share UI between routes and an IndexRoute is just the default, base route of a nested route. Let's see it.
156 |
157 | Make a new file called Layout.jsx. Put:
158 |
159 | {% highlight javascript %}
160 | const React = require('react')
161 |
162 | const Layout = (props) => (
163 |
132 |
133 |
137 | {props.title}
134 |({props.year})
135 |{props.description}
136 |
164 | {props.children}
165 |
166 | )
167 |
168 | module.exports = Layout
169 | {% endhighlight %}
170 |
171 | In ClientApp, pull in the IndexRoute component from react-router and make a nested route in your component.
172 |
173 | {% highlight javascript %}
174 | const React = require('react')
175 | const ReactDOM = require('react-dom')
176 | const Landing = require('./Landing')
177 | const Search = require('./Search')
178 | const Layout = require('./Layout')
179 | const ReactRouter = require('react-router')
180 | const { Router, Route, hashHistory, IndexRoute } = ReactRouter
181 |
182 | const App = () => (
183 | children is in particular an interesting beast. It allows you to make a tag and have access to whatever's inside. So:
195 |
196 | {% highlight html %}
197 |