101 |
--------------------------------------------------------------------------------
/examples/tagCloud/.gitignore:
--------------------------------------------------------------------------------
1 | # See https://help.github.com/ignore-files/ for more about ignoring files.
2 |
3 | # dependencies
4 | /node_modules
5 | /build
6 |
--------------------------------------------------------------------------------
/examples/tagCloud/README.md:
--------------------------------------------------------------------------------
1 | This project was bootstrapped with [Create React App](https://github.com/facebookincubator/create-react-app).
2 |
3 | Below you will find some information on how to perform common tasks.4 | You can find the most recent version of this guide [here](https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md). 5 | 6 | ## Table of Contents 7 | 8 | - [Updating to New Releases](#updating-to-new-releases) 9 | - [Sending Feedback](#sending-feedback) 10 | - [Folder Structure](#folder-structure) 11 | - [Available Scripts](#available-scripts) 12 | - [npm start](#npm-start) 13 | - [npm test](#npm-test) 14 | - [npm run build](#npm-run-build) 15 | - [npm run eject](#npm-run-eject) 16 | - [Supported Language Features and Polyfills](#supported-language-features-and-polyfills) 17 | - [Syntax Highlighting in the Editor](#syntax-highlighting-in-the-editor) 18 | - [Displaying Lint Output in the Editor](#displaying-lint-output-in-the-editor) 19 | - [Debugging in the Editor](#debugging-in-the-editor) 20 | - [Formatting Code Automatically](#formatting-code-automatically) 21 | - [Changing the Page `
929 | Please refer to the [dotenv documentation](https://github.com/motdotla/dotenv) for more details. 930 | 931 | >Note: If you are defining environment variables for development, your CI and/or hosting platform will most likely need 932 | these defined as well. Consult their documentation how to do this. For example, see the documentation for [Travis CI](https://docs.travis-ci.com/user/environment-variables/) or [Heroku](https://devcenter.heroku.com/articles/config-vars). 933 | 934 | ## Can I Use Decorators? 935 | 936 | Many popular libraries use [decorators](https://medium.com/google-developers/exploring-es7-decorators-76ecb65fb841) in their documentation.
937 | Create React App doesn’t support decorator syntax at the moment because: 938 | 939 | * It is an experimental proposal and is subject to change. 940 | * The current specification version is not officially supported by Babel. 941 | * If the specification changes, we won’t be able to write a codemod because we don’t use them internally at Facebook. 942 | 943 | However in many cases you can rewrite decorator-based code without decorators just as fine.
944 | Please refer to these two threads for reference: 945 | 946 | * [#214](https://github.com/facebookincubator/create-react-app/issues/214) 947 | * [#411](https://github.com/facebookincubator/create-react-app/issues/411) 948 | 949 | Create React App will add decorator support when the specification advances to a stable stage. 950 | 951 | ## Integrating with an API Backend 952 | 953 | These tutorials will help you to integrate your app with an API backend running on another port, 954 | using `fetch()` to access it. 955 | 956 | ### Node 957 | Check out [this tutorial](https://www.fullstackreact.com/articles/using-create-react-app-with-a-server/). 958 | You can find the companion GitHub repository [here](https://github.com/fullstackreact/food-lookup-demo). 959 | 960 | ### Ruby on Rails 961 | 962 | Check out [this tutorial](https://www.fullstackreact.com/articles/how-to-get-create-react-app-to-work-with-your-rails-api/). 963 | You can find the companion GitHub repository [here](https://github.com/fullstackreact/food-lookup-demo-rails). 964 | 965 | ## Proxying API Requests in Development 966 | 967 | >Note: this feature is available with `react-scripts@0.2.3` and higher. 968 | 969 | People often serve the front-end React app from the same host and port as their backend implementation.
970 | For example, a production setup might look like this after the app is deployed: 971 | 972 | ``` 973 | / - static server returns index.html with React app 974 | /todos - static server returns index.html with React app 975 | /api/todos - server handles any /api/* requests using the backend implementation 976 | ``` 977 | 978 | 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. 979 | 980 | 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: 981 | 982 | ```js 983 | "proxy": "http://localhost:4000", 984 | ``` 985 | 986 | 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. 987 | 988 | Conveniently, this avoids [CORS issues](http://stackoverflow.com/questions/21854516/understanding-ajax-cors-and-security-considerations) and error messages like this in development: 989 | 990 | ``` 991 | 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. 992 | ``` 993 | 994 | 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`. 995 | 996 | The `proxy` option supports HTTP, HTTPS and WebSocket connections.
997 | If the `proxy` option is **not** flexible enough for you, alternatively you can: 998 | 999 | * [Configure the proxy yourself](#configuring-the-proxy-manually) 1000 | * Enable CORS on your server ([here’s how to do it for Express](http://enable-cors.org/server_expressjs.html)). 1001 | * Use [environment variables](#adding-custom-environment-variables) to inject the right server host and port into your app. 1002 | 1003 | ### "Invalid Host Header" Errors After Configuring Proxy 1004 | 1005 | When you enable the `proxy` option, you opt into a more strict set of host checks. This is necessary because leaving the backend open to remote hosts makes your computer vulnerable to DNS rebinding attacks. The issue is explained in [this article](https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a) and [this issue](https://github.com/webpack/webpack-dev-server/issues/887). 1006 | 1007 | This shouldn’t affect you when developing on `localhost`, but if you develop remotely like [described here](https://github.com/facebookincubator/create-react-app/issues/2271), you will see this error in the browser after enabling the `proxy` option: 1008 | 1009 | >Invalid Host header 1010 | 1011 | To work around it, you can specify your public development host in a file called `.env.development` in the root of your project: 1012 | 1013 | ``` 1014 | HOST=mypublicdevhost.com 1015 | ``` 1016 | 1017 | If you restart the development server now and load the app from the specified host, it should work. 1018 | 1019 | If you are still having issues or if you’re using a more exotic environment like a cloud editor, you can bypass the host check completely by adding a line to `.env.development.local`. **Note that this is dangerous and exposes your machine to remote code execution from malicious websites:** 1020 | 1021 | ``` 1022 | # NOTE: THIS IS DANGEROUS! 1023 | # It exposes your machine to attacks from the websites you visit. 1024 | DANGEROUSLY_DISABLE_HOST_CHECK=true 1025 | ``` 1026 | 1027 | We don’t recommend this approach. 1028 | 1029 | ### Configuring the Proxy Manually 1030 | 1031 | >Note: this feature is available with `react-scripts@1.0.0` and higher. 1032 | 1033 | If the `proxy` option is **not** flexible enough for you, you can specify an object in the following form (in `package.json`).
1034 | You may also specify any configuration value [`http-proxy-middleware`](https://github.com/chimurai/http-proxy-middleware#options) or [`http-proxy`](https://github.com/nodejitsu/node-http-proxy#options) supports. 1035 | ```js 1036 | { 1037 | // ... 1038 | "proxy": { 1039 | "/api": { 1040 | "target": "
1185 | >[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) 1186 | 1187 | 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. 1188 | 1189 | 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. 1190 | 1191 | 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. 1192 | 1193 | 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. 1194 | 1195 | ### Filename Conventions 1196 | 1197 | Jest will look for test files with any of the following popular naming conventions: 1198 | 1199 | * Files with `.js` suffix in `__tests__` folders. 1200 | * Files with `.test.js` suffix. 1201 | * Files with `.spec.js` suffix. 1202 | 1203 | The `.test.js` / `.spec.js` files (or the `__tests__` folders) can be located at any depth under the `src` top level folder. 1204 | 1205 | 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. 1206 | 1207 | ### Command Line Interface 1208 | 1209 | 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. 1210 | 1211 | 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: 1212 | 1213 |  1214 | 1215 | ### Version Control Integration 1216 | 1217 | 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. 1218 | 1219 | 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. 1220 | 1221 | 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. 1222 | 1223 | ### Writing Tests 1224 | 1225 | 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. 1226 | 1227 | Jest provides a built-in `expect()` global function for making assertions. A basic test could look like this: 1228 | 1229 | ```js 1230 | import sum from './sum'; 1231 | 1232 | it('sums numbers', () => { 1233 | expect(sum(1, 2)).toEqual(3); 1234 | expect(sum(2, 2)).toEqual(4); 1235 | }); 1236 | ``` 1237 | 1238 | All `expect()` matchers supported by Jest are [extensively documented here](http://facebook.github.io/jest/docs/expect.html).
1239 | 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. 1240 | 1241 | ### Testing Components 1242 | 1243 | 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. 1244 | 1245 | 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: 1246 | 1247 | ```js 1248 | import React from 'react'; 1249 | import ReactDOM from 'react-dom'; 1250 | import App from './App'; 1251 | 1252 | it('renders without crashing', () => { 1253 | const div = document.createElement('div'); 1254 | ReactDOM.render(