« Previous Tutorial Next Tutorial »

We’re back again with another installment of Five Minute React. In our last tutorial, we got Webpack hot reloading up and running. That’s a nice thing to have, and it’ll allow us to move forward with React development. Before we do that, though, let’s recap where we are:

  • We’ve gotten our development tools and servers set up
  • We’ve scaffolded our Express app
  • We’ve created a simple API endpoint
  • We’ve tested that endpoint
  • We’ve gotten React up and running with test components
  • We’ve added hot-reloading to our app

That’s a lot! I hope the tutorials have been instructive and helpful so far. There are a lot more yet to come, and a there’s a lot more left to learn, so let’s get to it.

Today we’re going to set up some directories for our react app, nuke our test component, and build a frame to hold future components. After that, we’re going to need to be able to navigate between components, which means we’ll be tackling front-end routing, but that’s a whole other tutorial … probably two or even three, actually.

Let’s start with our /src directory. We obviously don’t want to keep our entire React app at the top level, so we’re going to create some subdirectories. As an added bonus, these directories are going to give you an advance look at future tutorials, in which we’ll cover, well, how the hell all this stuff works. For now, create the following folders underneath /src:

  • /actions
  • /components
  • /reducers
  • /utils

With that done, go ahead and delete /src/testcomponent.jsx … yes, this means our beautiful little React app will no longer work, but don’t worry, it won’t be broken for long. Let’s talk about these directories real quick … actions are what we’ll be using to communicate changes in state to our application. Components will hold our React components, everything from page templates down to little boxes, buttons, and doodads. Reducers are what take input from the actions, and then store the state changes in what’s conveniently referred to as the Store. Utils will be small JavaScript files full of handy stuff that we can import if we need it.

I’m not going to get into actions and reducers today, let alone cover the basics of Redux, with which we’ll be managing all of that, but I do want to talk for a minute about Application State. This is an important concept to understand when moving forward with React development. Your app state is a collection of data that represents, well, the state of your app. That is to say: what’s going on. You know how on most modern websites, you can click, say, a tabbed menu atop a box, and the content of the box will change to reflect which tab you’ve clicked? That’s a change in app state. Your app is being told which tab was clicked, and acting accordingly to either fill the box with the appropriate data or, at least, hide various HTML containers that contain data for the other tabs, and show the HTML container that contains data relevant to the tab we clicked (not to mention highlighting the tab, which is another change in app state).

To put it in jQuery terms, all of these change app state:

$('#myDiv').html('This is new text for the div.');

The reason for using React over something like jQuery to manage this stuff is because of all the automagic that happens under the hood. Instead of having to update a div with text, we can just change a component’s prop, giving it the text we want, and React will automatically render that. We don’t end up having to write a zillion .show() and .hide() and .html() functions for the various pieces of our app, resulting in a much more compartmentalized and less cumbersome approach to application development. Additionally, there are also performance things React does in the background that make it extremely fast when it comes to re-rendering part of the page, so that’s an added bonus.

I’m simplifying this a bit, because as we’ll discover later, we won’t actually store all of this information in the Store, because in some cases we only need to keep track of state at the component level, but for now the best way to think about it is as follows: every piece of dynamic data in your app is inherently part of its state. Whether it’s information we’ve pulled from an API and are displaying on the page, or the shown/hidden state of a component, it’s all app state.

All right, let’s build our container. Create a file in /src/components called Template.jsx (yes, with a capital T – it’s convention for React components). Then fill it with the following code:

import React from 'react';

export default function Template() {
  return (
    <div className="wrapper">
      <div className="content">
        Content will eventually go here.

Not really much different than our test component, I’ll admit, but that file’s going to change a lot in subsequent tutorials. Note that we’re using className instead of class – this is because class is a reserved word in JavaScript. Don’t worry; React will render it out as “class” in the HTML it generates. For now, save the file and switch over to /src/index.jsx. We need to update this file to use our template instead of our now-nonexistent test component. We don’t need to write any new codes, we just need to change four lines. Specifically the following ones …

Line 5:

import TestComponent from './testcomponent';


import Template from './components/Template';

Line 16:




Line 19

  module.hot.accept('./testcomponent', () => {


  module.hot.accept('./components/Template', () => {

And Line 20




… that’s it. If your webpack dev server isn’t running, launch it with:

yarn run start-w

and then save this file. If you still have your browser open, you should see it hot-reload with the changes. If not, navigate to localhost:3000 to see the new stuff.

That’s all for this tutorial. Next time we’ll create a few more components and wire them together before tackling React routing. See you there!

« Previous Tutorial Next Tutorial »