This project was originally created with Create React App, but has been modified to include:

• SASS support
• Bootstrap 3
• Mocha/Enzyme/Sinon for testing instead of Jest
• Redux
• React Router
• Linting

Todo:

• Redux thunk

To Consider implementing:

• ES7 async/await functionality

Below you will find some information on how to perform common tasks.
You can find the most recent version of this guide here.

Folder Structure

After creation, your project should look like this:

(TODO: update this)

my-app/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
  src/
    App.css
    App.js
    App.test.js
    index.css
    index.js
    logo.svg

For the project to build, these files must exist with exact filenames:

• public/index.html is the page template;
• src/index.js is the JavaScript entry point.

You can delete or rename the other files.

You may create subdirectories inside src. For faster rebuilds, only files inside src are processed by Webpack.
You need to put any JS and CSS files inside src, or Webpack won’t see them.

Only files inside public can be used from public/index.html.
Read instructions below for using assets from JavaScript and HTML.

You can, however, create more top-level directories.
They will not be included in the production build so you can use them for things like documentation.

Available Scripts

In the project directory, you can run:

npm start

Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.

The page will reload if you make edits.
You will also see any lint errors in the console.

npm test

Launches the test runner. Use npm run test:watch to watch and rerun tests.

npm run build

Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.
Your app is ready to be deployed!

Displaying Lint Output in the Editor

Note: this feature is available with [email protected] and higher.

Some editors, including Sublime Text, Atom, and Visual Studio Code, provide plugins for ESLint.

They are not required for linting. You should see the linter output right in your terminal as well as the browser console. However, if you prefer the lint results to appear right in your editor, there are some extra steps you can do.

You would need to install an ESLint plugin for your editor first.

A note for Atom linter-eslint users

(TODO: follow the TW guidelines)

If you are using the Atom linter-eslint plugin, make sure that Use global ESLint installation option is checked:

Then add this block to the package.json file of your project:

{
  // ...
  "eslintConfig": {
    "extends": "react-app"
  }
}

Finally, you will need to install some packages globally:

npm install -g [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

We recognize that this is suboptimal, but it is currently required due to the way we hide the ESLint dependency. The ESLint team is already working on a solution to this so this may become unnecessary in a couple of months.

Importing a Component

This project setup supports ES6 modules thanks to Babel.
While you can still use require() and module.exports, we encourage you to use import and export instead.

For example:

Button.js

import React, { Component } from 'react';

class Button extends Component {
  render() {
    // ...
  }
}

export default Button; // Don’t forget to use export default!

DangerButton.js

import React, { Component } from 'react';
import Button from './Button'; // Import a component from another file

class DangerButton extends Component {
  render() {
    return <Button color="red" />;
  }
}

export default DangerButton;

Be aware of the difference between default and named exports. It is a common source of mistakes.

We suggest that you stick to using default imports and exports when a module only exports a single thing (for example, a component). That’s what you get when you use export default Button and import Button from './Button'.

Named exports are useful for utility modules that export several functions. A module may have at most one default export and as many named exports as you like.

Learn more about ES6 modules:

• When to use the curly braces?
• Exploring ES6: Modules
• Understanding ES6: Modules

Adding a Stylesheet

This project setup uses Webpack for handling all assets. Webpack offers a custom way of “extending” the concept of import beyond JavaScript. To express that a JavaScript file depends on a CSS file, you need to import the CSS from the JavaScript file:

Button.css

.Button {
  padding: 20px;
}

Button.js

import React, { Component } from 'react';
import './Button.css'; // Tell Webpack that Button.js uses these styles

class Button extends Component {
  render() {
    // You can use them as regular CSS styles
    return <div className="Button" />;
  }
}

This is not required for React but many people find this feature convenient. You can read about the benefits of this approach here. However you should be aware that this makes your code less portable to other build tools and environments than Webpack.

In development, expressing dependencies this way allows your styles to be reloaded on the fly as you edit them. In production, all CSS files will be concatenated into a single minified .css file in the build output.

If you are concerned about using Webpack-specific semantics, you can put all your CSS right into src/index.css. It would still be imported from src/index.js, but you could always remove that import if you later migrate to a different build tool.

Note about SASS

TK

Post-Processing CSS

This project setup minifies your CSS and adds vendor prefixes to it automatically through Autoprefixer so you don’t need to worry about it.

For example, this:

.App {
  display: flex;
  flex-direction: row;
  align-items: center;
}

becomes this:

.App {
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-box-orient: horizontal;
  -webkit-box-direction: normal;
      -ms-flex-direction: row;
          flex-direction: row;
  -webkit-box-align: center;
      -ms-flex-align: center;
          align-items: center;
}

There is currently no support for preprocessors such as Less, or for sharing variables across CSS files.

Adding Images and Fonts

With Webpack, using static assets like images and fonts works similarly to CSS.

You can import an image right in a JavaScript module. This tells Webpack to include that image in the bundle. Unlike CSS imports, importing an image or a font gives you a string value. This value is the final image path you can reference in your code.

Here is an example:

import React from 'react';
import logo from './logo.png'; // Tell Webpack this JS file uses this image

console.log(logo); // /logo.84287d09.png

function Header() {
  // Import result is the URL of your image
  return <img src={logo} alt="Logo" />;
}

export default function Header;

This ensures that when the project is built, Webpack will correctly move the images into the build folder, and provide us with correct paths.

This works in CSS too:

.Logo {
  background-image: url(./logo.png);
}

Webpack finds all relative module references in CSS (they start with ./) and replaces them with the final paths from the compiled bundle. If you make a typo or accidentally delete an important file, you will see a compilation error, just like when you import a non-existent JavaScript module. The final filenames in the compiled bundle are generated by Webpack from content hashes. If the file content changes in the future, Webpack will give it a different name in production so you don’t need to worry about long-term caching of assets.

Please be advised that this is also a custom feature of Webpack.

It is not required for React but many people enjoy it (and React Native uses a similar mechanism for images).
An alternative way of handling static assets is described in the next section.

Using the public Folder

Normally we encourage you to import assets in JavaScript files as described above. This mechanism provides a number of benefits:

• Scripts and stylesheets get minified and bundled together to avoid extra network requests.
• Missing files cause compilation errors instead of 404 errors for your users.
• Result filenames include content hashes so you don’t need to worry about browsers caching their old versions.

However there is an escape hatch that you can use to add an asset outside of the module system.

If you put a file into the public folder, it will not be processed by Webpack. Instead it will be copied into the build folder untouched. To reference assets in the public folder, you need to use a special variable called PUBLIC_URL.

Inside index.html, you can use it like this:

<link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico">

Only files inside the public folder will be accessible by %PUBLIC_URL% prefix. If you need to use a file from src or node_modules, you’ll have to copy it there to explicitly specify your intention to make this file a part of the build.

When you run npm run build, Create React App will substitute %PUBLIC_URL% with a correct absolute path so your project works even if you use client-side routing or host it at a non-root URL.

In JavaScript code, you can use process.env.PUBLIC_URL for similar purposes:

render() {
  // Note: this is an escape hatch and should be used sparingly!
  // Normally we recommend using `import` for getting asset URLs
  // as described in “Adding Images and Fonts” above this section.
  return <img src={process.env.PUBLIC_URL + '/img/logo.png'} />;
}

Keep in mind the downsides of this approach:

• None of the files in public folder get post-processed or minified.
• Missing files will not be called at compilation time, and will cause 404 errors for your users.
• Result filenames won’t include content hashes so you’ll need to add query arguments or rename them every time they change.

However, it can be handy for referencing assets like manifest.webmanifest from HTML, or including small scripts like pace.js outside of the bundled code.

Importing CSS (or SASS) libraries

TODO: flesh this out

Webpack loads node_modules by default with sass-loader, so you can load them sass style like @import "~mylib/dist/stuff";.

Adding Development Environment Variables In .env

To define permanent environment variables, create a file called .env in the root of your project:

REACT_APP_SECRET_CODE=abcdef

These variables will act as the defaults if the machine does not explicitly set them.
Please refer to the dotenv documentation for more details.

Note: If you are defining environment variables for development, your CI and/or hosting platform will most likely need these defined as well. Consult their documentation how to do this. For example, see the documentation for Travis CI or Heroku.

Can I Use Decorators?

Many popular libraries use decorators in their documentation.
Reboiler doesn’t support decorator syntax at the moment because:

• It is an experimental proposal and is subject to change.
• The current specification version is not officially supported by Babel.
• If the specification changes, we won’t be able to write a codemod because we don’t use them internally at Facebook.

However in many cases you can rewrite decorator-based code without decorators just as fine.
Please refer to these two threads for reference:

• #214
• #411

Integrating with a Node Backend

Check out this tutorial for instructions on integrating an app with a Node backend running on another port, and using fetch() to access it. You can find the companion GitHub repository here.

TODO: this may not be exact for our needs.

Proxying API Requests in Development

People often serve the front-end React app from the same host and port as their backend implementation.
For example, a production setup might look like this after the app is deployed:

/             - static server returns index.html with React app
/todos        - static server returns index.html with React app
/api/todos    - server handles any /api/* requests using the backend implementation

Such setup is not required. However, if you do have a setup like this, it is convenient to write requests like fetch('/api/todos') without worrying about redirecting them to another host or port during development.

To tell the development server to proxy any unknown requests to your API server in development, add a proxy field to your package.json, for example:

  "proxy": "http://localhost:4000",

This way, when you fetch('/api/todos') in development, the development server will recognize that it’s not a static asset, and will proxy your request to http://localhost:4000/api/todos as a fallback. The development server will only attempt to send requests without a text/html accept header to the proxy.

Conveniently, this avoids CORS issues and error messages like this in development:

Fetch API cannot load http://localhost:4000/api/todos. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Keep in mind that proxy only has effect in development (with npm start), and it is up to you to ensure that URLs like /api/todos point to the right thing in production. You don’t have to use the /api prefix. Any unrecognized request without a text/html accept header will be redirected to the specified proxy.

Currently the proxy option only handles HTTP requests, and it won’t proxy WebSocket connections.
If the proxy option is not flexible enough for you, alternatively you can:

• Enable CORS on your server (here’s how to do it for Express).
• Use environment variables to inject the right server host and port into your app.

Using HTTPS in Development

You may require the dev server to serve pages over HTTPS. One particular case where this could be useful is when using the "proxy" feature to proxy requests to an API server when that API server is itself serving HTTPS.

To do this, set the HTTPS environment variable to true, then start the dev server as usual with npm start:

Windows (cmd.exe)

set HTTPS=true&&npm start

(Note: the lack of whitespace is intentional.)

Linux, OS X (Bash)

HTTPS=true npm start

Note that the server will use a self-signed certificate, so your web browser will almost definitely display a warning upon accessing the page.

Generating Dynamic <meta> Tags on the Server

Since Create React App doesn’t support server rendering, you might be wondering how to make <meta> tags dynamic and reflect the current URL. To solve this, we recommend to add placeholders into the HTML, like this:

<!doctype html>
<html lang="en">
  <head>
    <meta property="og:title" content="%OG_TITLE%">
    <meta property="og:description" content="%OG_DESCRIPTION%">

Then, on the server, regardless of the backend you use, you can read index.html into memory and replace %OG_TITLE%, %OG_DESCRIPTION%, and any other placeholders with values depending on the current URL. Just make sure to sanitize and escape the interpolated values so that they are safe to embed into HTML!

If you use a Node server, you can even share the route matching logic between the client and the server. However duplicating it also works fine in simple cases.

Running Tests

TK

Deployment

Building for Relative Paths

By default, Create React App produces a build assuming your app is hosted at the server root.
To override this, specify the homepage in your package.json, for example:

  "homepage": "http://mywebsite.com/relativepath",

This will let Create React App correctly infer the root path to use in the generated HTML file.

Heroku

Use the Heroku Buildpack for Create React App.
You can find instructions in Deploying React with Zero Configuration.

Modulus

See the Modulus blog post on how to deploy your react app to Modulus.

Netlify

To do a manual deploy to Netlify's CDN:

npm install netlify-cli
netlify deploy

Choose build as the path to deploy.

To setup continuous delivery:

With this setup Netlify will build and deploy when you push to git or open a pull request:

1. Start a new netlify project
2. Pick your Git hosting service and select your repository
3. Click Build your site

Support for client-side routing:

To support pushState, make sure to create a public/_redirects file with the following rewrite rules:

/*  /index.html  200

When you build the project, Create React App will place the public folder contents into the build output.

Now

See this example for a zero-configuration single-command deployment with now.

Surge

Install the Surge CLI if you haven't already by running npm install -g surge. Run the surge command and log in you or create a new account. You just need to specify the build folder and your custom domain, and you are done.

              email: [email protected]
           password: ********
       project path: /path/to/project/build
               size: 7 files, 1.8 MB
             domain: create-react-app.surge.sh
             upload: [====================] 100%, eta: 0.0s
   propagate on CDN: [====================] 100%
               plan: Free
              users: [email protected]
         IP Address: X.X.X.X

    Success! Project is published and running at create-react-app.surge.sh

Note that in order to support routers that use HTML5 pushState API, you may want to rename the index.html in your build folder to 200.html before deploying to Surge. This ensures that every URL falls back to that file.

Something Missing?

If you have ideas for more “How To” recipes that should be on this page, let us know or contribute some!