478 | );
479 | }
480 | }
481 |
482 | export default App;
483 | ```
484 |
485 | This will make `moduleA.js` and all its unique dependencies as a separate chunk that only loads after the user clicks the 'Load' button.
486 |
487 | You can also use it with `async` / `await` syntax if you prefer it.
488 |
489 | ### With React Router
490 |
491 | If you are using React Router check out [this tutorial](http://serverless-stack.com/chapters/code-splitting-in-create-react-app.html) on how to use code splitting with it. You can find the companion GitHub repository [here](https://github.com/AnomalyInnovations/serverless-stack-demo-client/tree/code-splitting-in-create-react-app).
492 |
493 | ## Adding a Stylesheet
494 |
495 | This project setup uses [Webpack](https://webpack.js.org/) 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**:
496 |
497 | ### `Button.css`
498 |
499 | ```css
500 | .Button {
501 | padding: 20px;
502 | }
503 | ```
504 |
505 | ### `Button.js`
506 |
507 | ```js
508 | import React, { Component } from 'react';
509 | import './Button.css'; // Tell Webpack that Button.js uses these styles
510 |
511 | class Button extends Component {
512 | render() {
513 | // You can use them as regular CSS styles
514 | return ;
515 | }
516 | }
517 | ```
518 |
519 | **This is not required for React** but many people find this feature convenient. You can read about the benefits of this approach [here](https://medium.com/seek-ui-engineering/block-element-modifying-your-javascript-components-d7f99fcab52b). However you should be aware that this makes your code less portable to other build tools and environments than Webpack.
520 |
521 | 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.
522 |
523 | 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.
524 |
525 | ## Using the `public` Folder
526 |
527 | >Note: this feature is available with `react-scripts@0.5.0` and higher.
528 |
529 | ### Changing the HTML
530 |
531 | The `public` folder contains the HTML file so you can tweak it, for example, to [set the page title](#changing-the-page-title).
532 | The `
1040 | ```
1041 |
1042 | Then, on the server, you can replace `__SERVER_DATA__` with a JSON of real data right before sending the response. The client code can then read `window.SERVER_DATA` to use it. **Make sure to [sanitize the JSON before sending it to the client](https://medium.com/node-security/the-most-common-xss-vulnerability-in-react-js-applications-2bdffbcc1fa0) as it makes your app vulnerable to XSS attacks.**
1043 |
1044 | ## Running Tests
1045 |
1046 | >Note: this feature is available with `react-scripts@0.3.0` and higher.
1047 | >[Read the migration guide to learn how to enable it in older projects!](https://github.com/facebookincubator/create-react-app/blob/master/CHANGELOG.md#migrating-from-023-to-030)
1048 |
1049 | Create React App uses [Jest](https://facebook.github.io/jest/) as its test runner. To prepare for this integration, we did a [major revamp](https://facebook.github.io/jest/blog/2016/09/01/jest-15.html) of Jest so if you heard bad things about it years ago, give it another try.
1050 |
1051 | Jest is a Node-based runner. This means that the tests always run in a Node environment and not in a real browser. This lets us enable fast iteration speed and prevent flakiness.
1052 |
1053 | While Jest provides browser globals such as `window` thanks to [jsdom](https://github.com/tmpvar/jsdom), they are only approximations of the real browser behavior. Jest is intended to be used for unit tests of your logic and your components rather than the DOM quirks.
1054 |
1055 | We recommend that you use a separate tool for browser end-to-end tests if you need them. They are beyond the scope of Create React App.
1056 |
1057 | ### Filename Conventions
1058 |
1059 | Jest will look for test files with any of the following popular naming conventions:
1060 |
1061 | * Files with `.js` suffix in `__tests__` folders.
1062 | * Files with `.test.js` suffix.
1063 | * Files with `.spec.js` suffix.
1064 |
1065 | The `.test.js` / `.spec.js` files (or the `__tests__` folders) can be located at any depth under the `src` top level folder.
1066 |
1067 | We recommend to put the test files (or `__tests__` folders) next to the code they are testing so that relative imports appear shorter. For example, if `App.test.js` and `App.js` are in the same folder, the test just needs to `import App from './App'` instead of a long relative path. Colocation also helps find tests more quickly in larger projects.
1068 |
1069 | ### Command Line Interface
1070 |
1071 | When you run `npm test`, Jest will launch in the watch mode. Every time you save a file, it will re-run the tests, just like `npm start` recompiles the code.
1072 |
1073 | The watcher includes an interactive command-line interface with the ability to run all tests, or focus on a search pattern. It is designed this way so that you can keep it open and enjoy fast re-runs. You can learn the commands from the “Watch Usage” note that the watcher prints after every run:
1074 |
1075 | 
1076 |
1077 | ### Version Control Integration
1078 |
1079 | By default, when you run `npm test`, Jest will only run the tests related to files changed since the last commit. This is an optimization designed to make your tests run fast regardless of how many tests you have. However it assumes that you don’t often commit the code that doesn’t pass the tests.
1080 |
1081 | Jest will always explicitly mention that it only ran tests related to the files changed since the last commit. You can also press `a` in the watch mode to force Jest to run all tests.
1082 |
1083 | Jest will always run all tests on a [continuous integration](#continuous-integration) server or if the project is not inside a Git or Mercurial repository.
1084 |
1085 | ### Writing Tests
1086 |
1087 | To create tests, add `it()` (or `test()`) blocks with the name of the test and its code. You may optionally wrap them in `describe()` blocks for logical grouping but this is neither required nor recommended.
1088 |
1089 | Jest provides a built-in `expect()` global function for making assertions. A basic test could look like this:
1090 |
1091 | ```js
1092 | import sum from './sum';
1093 |
1094 | it('sums numbers', () => {
1095 | expect(sum(1, 2)).toEqual(3);
1096 | expect(sum(2, 2)).toEqual(4);
1097 | });
1098 | ```
1099 |
1100 | All `expect()` matchers supported by Jest are [extensively documented here](http://facebook.github.io/jest/docs/expect.html).
1101 | You can also use [`jest.fn()` and `expect(fn).toBeCalled()`](http://facebook.github.io/jest/docs/expect.html#tohavebeencalled) to create “spies” or mock functions.
1102 |
1103 | ### Testing Components
1104 |
1105 | There is a broad spectrum of component testing techniques. They range from a “smoke test” verifying that a component renders without throwing, to shallow rendering and testing some of the output, to full rendering and testing component lifecycle and state changes.
1106 |
1107 | Different projects choose different testing tradeoffs based on how often components change, and how much logic they contain. If you haven’t decided on a testing strategy yet, we recommend that you start with creating simple smoke tests for your components:
1108 |
1109 | ```js
1110 | import React from 'react';
1111 | import ReactDOM from 'react-dom';
1112 | import App from './App';
1113 |
1114 | it('renders without crashing', () => {
1115 | const div = document.createElement('div');
1116 | ReactDOM.render(, div);
1117 | });
1118 | ```
1119 |
1120 | This test mounts a component and makes sure that it didn’t throw during rendering. Tests like this provide a lot value with very little effort so they are great as a starting point, and this is the test you will find in `src/App.test.js`.
1121 |
1122 | When you encounter bugs caused by changing components, you will gain a deeper insight into which parts of them are worth testing in your application. This might be a good time to introduce more specific tests asserting specific expected output or behavior.
1123 |
1124 | If you’d like to test components in isolation from the child components they render, we recommend using [`shallow()` rendering API](http://airbnb.io/enzyme/docs/api/shallow.html) from [Enzyme](http://airbnb.io/enzyme/). To install it, run:
1125 |
1126 | ```sh
1127 | npm install --save enzyme react-test-renderer
1128 | ```
1129 |
1130 | Alternatively you may use `yarn`:
1131 |
1132 | ```sh
1133 | yarn add enzyme react-test-renderer
1134 | ```
1135 |
1136 | You can write a smoke test with it too:
1137 |
1138 | ```js
1139 | import React from 'react';
1140 | import { shallow } from 'enzyme';
1141 | import App from './App';
1142 |
1143 | it('renders without crashing', () => {
1144 | shallow();
1145 | });
1146 | ```
1147 |
1148 | Unlike the previous smoke test using `ReactDOM.render()`, this test only renders `` and doesn’t go deeper. For example, even if `` itself renders a `