12 | {{ content }}
13 |
14 | {{ page.title }}
8 |
11 | {{ content }}
12 |
13 |
14 |
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 | lol
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-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(npm run cover you should see 100% coverage on both Search and ShowCard. That means all the exported code is getting covered in a test! Yay! But where are the rest of our files? Well, we're not testing them at all yet so istanbul doesn't know about them. Once you start testing those files they'll show up.
14 |
15 | Now try adding an extra method to Search. It can be some dumb method that returns 5. Now run your npm run cover again. Your code will not be totally covered now. This is what istanbul gets you. If you open coverage/index.html in your browser, you'll actually be able to visualize what the code coverage looks like. Pretty sweet.
16 |
17 | [istanbul]: https://github.com/gotwarlost/istanbul
18 | [nyc]: https://github.com/bcoe/nyc
--------------------------------------------------------------------------------
/_posts/2016-01-13-hot-module-reload.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "A Note on Hot Module Reload"
3 | ---
4 |
5 | So webpack has a nifty ability to do what's called hot module reload (HMR.) If you've ever used LiveReload's CSS injection, this will sound familiar. HMR will take your code, compile it on the fly, and then inject it into your live-running code. Pretty cool tech.
6 |
7 | If you're working a dropdown that requires three different clicks to get there, it's pretty neat to be able to change the code and watch the UI change without having to reload and get the UI back into a state where you can see the effects of your change.
8 |
9 | But we're not going to do it today. For one, HMR does not work with our stateless functional components at all. So we'd have to convert everything to classes which is a burden. It also just requires a lot of setup that can be finicky at times. The author himself says [the tech is a (great) hack][hmr-death].
10 |
11 | So suffice to say, I want you to be aware of its existence and continuing evolution but I feel like our time is better off investigating other parts of the React ecosystem.
12 |
13 | [hmr-death]: https://medium.com/@dan_abramov/the-death-of-react-hot-loader-765fa791d7c4#.80xafsv2d
--------------------------------------------------------------------------------
/_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-15-react-tools.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "React Tools"
3 | ---
4 |
5 | So far we've been using pretty old school debugging technology: console.logs and just dumping stuff out to the DOM. There is an easier way! [React Dev Tools][github]! Grab it here for [Chrome][chrome] and [Firefox][firefox]. In _theory_ you can get the Chrome version working on Microsoft Edge, but good luck. If you're not using Chrome or Firefox, you're out of luck for now. They're talking about doing a standalone app but we'll see when that finally surfaces. I'll be talking about the Chrome version because that's the one I know the best.
6 |
7 | [github]: https://github.com/facebook/react-devtools
8 | [chrome]: https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi
9 | [firefox]: https://addons.mozilla.org/en-US/firefox/addon/react-devtools/
10 |
11 | Dev Tools allow you to explore the virtual DOM of React as if it was just a normal DOM tree. You can see what props and states are in each component and even modify the state of components. The virtual DOM explorer is by-far the most useful part of it.
12 |
13 | Find the Dev Tools in Chrome by opening the Chrome dev tools and the last tab (along side Console, Sources, Network, etc.) should be React on your page. If you don't see it try restarting your browser. If you _still_ don't see it, the tab won't show up if the extension can't detect React on the page. You may have a dated version of the dev tools. After that I'm not sure; it can be fickle sometimes.
14 |
15 | Feel free to poke around a bit here to familiarize yourself with what the React Dev Tools can do. Here are a couple of tricks for you:
16 |
17 | - If you right-click -> Inspect Element on something and then click the React tab, it will take you straight to that element in the virtual DOM.
18 | - Select something in the virtual DOM in the React tab. Now go to the Console tab and type
261 |
262 |
266 | {props.title}
263 |({props.year})
264 |{props.description}
265 |$r. It should be a reference to the element you have selected in the virtual DOM and you can manipulate it.
19 | - As a side note, you can do the above trick with the normal DOM explorer with $0, $1, $2, $3, and $4 instead where 0 is the last one you selected, 1 is the penultimate, etc.
20 | - iframes and Chrome extensions don't work with React Dev Tools as of writing.
--------------------------------------------------------------------------------
/_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 file:/// protocol. So we're going to use node's [http-server][http-server]. If you don't have it already just run npm install -g http-server. From there, navigate to your project's root directory and run http-server -p 5050 ./. Then open localhost:5050 in your browser.
23 |
24 | Now you should see three green circles with smaller orange circles circling the green ones on your Chrome tool bar. Click on that and that should show you the redux tools. This allows you to play with the redux tools. I'll let you toy with them but suffice to say they're pretty impressive.
25 |
26 | [chrome-extension]: https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd?hl=en
27 | [http-server]: https://github.com/indexzero/http-server
--------------------------------------------------------------------------------
/_posts/2016-01-18-fixing-tests.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Fixing Our Tests and Testing redux"
3 | ---
4 |
5 | So we broke all of our tests. They all fail now. High five! This is a big reason why I'm hesitant to test UI code: I find my tests break all the time just because I'm rewriting markup or other code. Nonetheless, let's refix our tests and add two for redux. As opposed to testing React which I don't do much of, I test the hell out of my redux code. redux code is very testable and you should cover all or nearly-all of your reducers with tests.
6 |
7 | Cool, open our spec doc. Let's fix these tests one-at-a-time. For the last two tests, change their method calls from it( ... ) to xit( ... ). This will prevent Mocha from running them so we can work on them one-at-a-time.
8 |
9 | The first test is actually testing Header so let's move it to its own describe too.
10 |
11 | {% highlight javascript %}
12 | // change what's pulled in from enzyme
13 | const { render } = enzyme
14 |
15 | // more requires
16 | const Header = require('../js/Header')
17 | const Store = require('../js/Store')
18 | const { store } = Store
19 |
20 | // new describe
21 | describe('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-20-ajax-and-lifecycle.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | title: "React Lifecycle Methods and AJAX with React"
3 | ---
4 |
5 | Due to the structuring of our app, we haven't had to use React lifecycle methods despite the fact they're fairly common to use and thus important to know. One of the most compelling reasons to use lifecycle methods is to do AJAX. Once a component gets mounted to the page then we want to be able request data from the server. First let's discuss the lifecycle of a React component.
6 |
7 | 1. __constructor/getInitialState__ - This is where set up your components initial state. The former is for ES6 classes (that we've been using) and the latter is for the React.createClass method.
8 | 1. __componentWillMount__ - This method runs right _before_ the component gets mounted. This one is not too common to use, but you will want to use it any time you want code to run both in node and in the browser.
9 | 1. __componentDidMount__ - This method runs right _after_ your component gets put into the DOM. This method _will not get run in node but will in the browser_. This makes it so your component can render first _then_ you can go get the data you need. In your component you can throw up a loader if you need to. Also if you need to interact with the DOM (like if you were wrapping D3 or a jQuery plugin) this would be the place to do it.
10 | 1. __componentWillUnmount__ - This method runs right before the component is taken off the DOM. Most common thing to do here is get rid of external event listeners or other things you need to clean up.
11 |
12 | Cool! So let's make our Details page check the IMDB rating! Open Details.jsx
13 |
14 | {% highlight javascript %}
15 | // require in axios
16 | const axios = require('axios')
17 |
18 | // add constructor and componentDidMount to Details
19 | constructor (props) {
20 | super(props)
21 |
22 | this.state = {
23 | omdbData: {}
24 | }
25 | }
26 | componentDidMount () {
27 | console.log('here', this.props.shows[this.props.params.id].imdbID)
28 | axios.get(`http://www.omdbapi.com/?i=${this.props.shows[this.props.params.id].imdbID}`)
29 | .then((response) => {
30 | this.setState({omdbData: response.data})
31 | })
32 | .catch((error) => {
33 | console.error('axios error', error)
34 | })
35 | }
36 |
37 | // add to render before return
38 | let rating
39 | if (this.state.omdbData.imdbRating) {
40 | rating = {this.state.omdbData.imdbRating}
41 | } 42 | 43 | // add between year and poster 44 | {rating} 45 | {% endhighlight %} 46 | 47 | We're requiring in [axios][axios] which is a great little promise-based AJAX client and using that to make requests to the Open Movie Database to find the IMDB ratings. If you go to your pages now you'll notice that the rating is showing up a little after the page renders. That's because it's being grabbed from the magical Internet tubes! As you can see, we did this componentDidMount so that the user could see UI before waiting on an AJAX request. Notice that it doesn't get server-side rendered either because the server doesn't call componentDidMount. 48 | 49 | That's it! That's all you need to need know about AJAX with React as well as the lifecycle methods! 50 | 51 | [axios]: https://github.com/mzabriskie/axios -------------------------------------------------------------------------------- /_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 (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 |
6 | {% for post in site.posts reversed %}
7 |
11 |
12 |
--------------------------------------------------------------------------------