Este proyecto se inició con la aplicación Create React.
A continuación encontrará información sobre cómo realizar tareas comunes.
Puede encontrar la versión más reciente de esta guía aquí.
<title>
public
public
.env
<meta>
dinámicas en el servidornpm start
no detecta cambiosnpm test
se bloquea en macOS Sierranpm run build
sale demasiado prontonpm run build
falla en Herokunpm run build
no logra minimizarLa aplicación Create React se divide en dos paquetes:
create-react-app
es una utilidad de línea de comandos global que se utiliza para crear nuevos proyectos.react-scripts
es una dependencia de desarrollo en los proyectos generados (incluido este). Casi nunca necesitas actualizar la propia create-react-app
: delega toda la configuración a react-scripts
.
Cuando ejecuta create-react-app
, siempre crea el proyecto con la última versión de react-scripts
por lo que obtendrá automáticamente todas las nuevas funciones y mejoras en las aplicaciones recién creadas.
Para actualizar un proyecto existente a una nueva versión de react-scripts
, abra el registro de cambios, busque la versión en la que se encuentra actualmente (consulte package.json
en esta carpeta si no está seguro) y aplique las instrucciones de migración para la versión más nueva. versiones.
En la mayoría de los casos, actualizar la versión de react-scripts
en package.json
y ejecutar npm install
en esta carpeta debería ser suficiente, pero es bueno consultar el registro de cambios para detectar posibles cambios importantes.
Nos comprometemos a mantener los cambios importantes al mínimo para que pueda actualizar react-scripts
sin problemas.
Siempre estamos abiertos a sus comentarios.
Después de la creación, su proyecto debería verse así:
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
Para que se pueda compilar el proyecto, estos archivos deben existir con nombres de archivo exactos :
public/index.html
es la plantilla de página;src/index.js
es el punto de entrada de JavaScript.Puede eliminar o cambiar el nombre de los otros archivos.
Puede crear subdirectorios dentro de src
. Para reconstrucciones más rápidas, Webpack solo procesa los archivos dentro de src
.
Debe colocar los archivos JS y CSS dentro de src
; de lo contrario, Webpack no los verá.
Solo se pueden utilizar archivos dentro de public
desde public/index.html
.
Lea las instrucciones a continuación para usar recursos de JavaScript y HTML.
Sin embargo, puede crear más directorios de nivel superior.
No se incluirán en la versión de producción, por lo que podrá utilizarlos para cosas como documentación.
En el directorio del proyecto, puede ejecutar:
npm start
Ejecuta la aplicación en modo de desarrollo.
Abra http://localhost:3000 para verlo en el navegador.
La página se recargará si realiza modificaciones.
También verá cualquier error de pelusa en la consola.
npm test
Inicia el corredor de prueba en el modo de reloj interactivo.
Consulte la sección sobre ejecución de pruebas para obtener más información.
npm run build
Crea la aplicación para producción en la carpeta build
.
Incluye correctamente React en modo de producción y optimiza la compilación para obtener el mejor rendimiento.
La compilación se minimiza y los nombres de archivos incluyen los hashes.
¡Su aplicación está lista para ser implementada!
Consulte la sección sobre implementación para obtener más información.
npm run eject
Nota: esta es una operación unidireccional. Una vez que eject
, ¡no podrás regresar!
Si no está satisfecho con la herramienta de compilación y las opciones de configuración, puede eject
en cualquier momento. Este comando eliminará la dependencia de compilación única de su proyecto.
En su lugar, copiará todos los archivos de configuración y las dependencias transitivas (Webpack, Babel, ESLint, etc.) directamente en su proyecto para que tenga control total sobre ellos. Todos los comandos, excepto eject
seguirán funcionando, pero apuntarán a los scripts copiados para que puedas modificarlos. En este punto estás solo.
No es necesario que uses nunca eject
. El conjunto de funciones seleccionado es adecuado para implementaciones pequeñas y medianas, y no debería sentirse obligado a utilizar esta función. Sin embargo, entendemos que esta herramienta no sería útil si no pudiera personalizarla cuando esté listo para usarla.
De forma predeterminada, el proyecto generado utiliza la última versión de React.
Puede consultar la documentación de React para obtener más información sobre los navegadores compatibles.
Este proyecto admite un superconjunto del último estándar de JavaScript.
Además de las funciones de sintaxis de ES6, también admite:
Obtenga más información sobre las diferentes etapas de la propuesta.
Si bien recomendamos usar propuestas experimentales con cierta precaución, Facebook usa mucho estas características en el código del producto, por lo que tenemos la intención de proporcionar modificaciones de código si alguna de estas propuestas cambia en el futuro.
Tenga en cuenta que el proyecto solo incluye algunos polyfills de ES6 :
Object.assign()
a través de object-assign
.Promise
mediante promise
.fetch()
a través de whatwg-fetch
. Si utiliza otras funciones de ES6+ que necesitan compatibilidad con el tiempo de ejecución (como Array.from()
o Symbol
), asegúrese de incluir manualmente los polyfills adecuados o de que los navegadores a los que se dirige ya los admitan.
También tenga en cuenta que el uso de algunas funciones de sintaxis más nuevas como for...of
o [...nonArrayValue]
hace que Babel emita código que depende de las funciones de tiempo de ejecución de ES6 y podría no funcionar sin un polyfill. En caso de duda, utilice Babel REPL para ver en qué se compila cualquier sintaxis específica.
Para configurar el resaltado de sintaxis en su editor de texto favorito, diríjase a la página de documentación de Babel correspondiente y siga las instrucciones. Se tratan algunos de los editores más populares.
Nota: esta función está disponible con
[email protected]
y superior.
También solo funciona con npm 3 o superior.
Algunos editores, incluidos Sublime Text, Atom y Visual Studio Code, proporcionan complementos para ESLint.
No son necesarios para quitar pelusa. Debería ver la salida de linter directamente en su terminal, así como en la consola del navegador. Sin embargo, si prefiere que los resultados de pelusa aparezcan directamente en su editor, hay algunos pasos adicionales que puede seguir.
Primero deberá instalar un complemento ESLint para su editor. Luego, agregue un archivo llamado .eslintrc
a la raíz del proyecto:
{
"extends" : "react-app"
}
Ahora su editor debería informar las advertencias de linting.
Tenga en cuenta que incluso si edita más su archivo .eslintrc
, estos cambios solo afectarán la integración del editor . No afectarán la salida de pelusa del terminal ni del navegador. Esto se debe a que la aplicación Create React proporciona intencionalmente un conjunto mínimo de reglas que encuentran errores comunes.
Si desea imponer un estilo de codificación para su proyecto, considere usar Prettier en lugar de las reglas de estilo ESLint.
Actualmente, esta característica solo es compatible con Visual Studio Code y WebStorm.
Visual Studio Code y WebStorm admiten la depuración lista para usar con la aplicación Create React. Esto le permite, como desarrollador, escribir y depurar su código React sin salir del editor y, lo más importante, le permite tener un flujo de trabajo de desarrollo continuo, donde el cambio de contexto es mínimo, ya que no tiene que cambiar entre herramientas.
Necesitará tener instalada la última versión de VS Code y VS Code Chrome Debugger Extension.
Luego agregue el siguiente bloque a su archivo launch.json
y colóquelo dentro de la carpeta .vscode
en el directorio raíz de su aplicación.
{
"version" : " 0.2.0 " ,
"configurations" : [{
"name" : " Chrome " ,
"type" : " chrome " ,
"request" : " launch " ,
"url" : " http://localhost:3000 " ,
"webRoot" : " ${workspaceRoot}/src " ,
"sourceMapPathOverrides" : {
"webpack:///src/*" : " ${webRoot}/* "
}
}]
}
Nota: la URL puede ser diferente si realizó ajustes a través de las variables de entorno HOST o PORT.
Inicie su aplicación ejecutando npm start
y comience a depurar en VS Code presionando F5
o haciendo clic en el ícono de depuración verde. Ahora puede escribir código, establecer puntos de interrupción, realizar cambios en el código y depurar el código recién modificado, todo desde su editor.
¿Tiene problemas con la depuración de código VS? Consulte su guía de solución de problemas.
Necesitará tener instalada la extensión de Chrome WebStorm y JetBrains IDE Support.
En el menú Run
de WebStorm, seleccione Edit Configurations...
Luego haga clic en +
y seleccione JavaScript Debug
. Pegue http://localhost:3000
en el campo URL y guarde la configuración.
Nota: la URL puede ser diferente si realizó ajustes a través de las variables de entorno HOST o PORT.
Inicie su aplicación ejecutando npm start
, luego presione ^D
en macOS o F9
en Windows y Linux o haga clic en el ícono de depuración verde para comenzar a depurar en WebStorm.
De la misma manera que puedes depurar tu aplicación en IntelliJ IDEA Ultimate, PhpStorm, PyCharm Pro y RubyMine.
Prettier es un formateador de código obstinado con soporte para JavaScript, CSS y JSON. Con Prettier puedes formatear el código que escribes automáticamente para garantizar un estilo de código dentro de tu proyecto. Consulte la página de GitHub de Prettier para obtener más información y mire esta página para verla en acción.
Para formatear nuestro código cada vez que realizamos una confirmación en git, necesitamos instalar las siguientes dependencias:
npm install --save husky lint-staged prettier
Alternativamente puedes usar yarn
:
yarn add husky lint-staged prettier
husky
facilita el uso de githooks como si fueran scripts npm.lint-staged
nos permite ejecutar scripts en archivos preparados en git. Consulte esta publicación de blog sobre lint-staged para obtener más información al respecto.prettier
es el formateador de JavaScript que ejecutaremos antes de las confirmaciones. Ahora podemos asegurarnos de que cada archivo tenga el formato correcto agregando algunas líneas al package.json
en la raíz del proyecto.
Agregue la siguiente línea a la sección scripts
:
"scripts": {
+ "precommit": "lint-staged",
"start": "react-scripts start",
"build": "react-scripts build",
A continuación agregamos un campo 'lint-staged' al package.json
, por ejemplo:
"dependencies": {
// ...
},
+ "lint-staged": {
+ "src/**/*.{js,jsx,json,css}": [
+ "prettier --single-quote --write",
+ "git add"
+ ]
+ },
"scripts": {
Ahora, cada vez que realice una confirmación, Prettier formateará los archivos modificados automáticamente. También puedes ejecutar ./node_modules/.bin/prettier --single-quote --write "src/**/*.{js,jsx,json,css}"
para formatear todo tu proyecto por primera vez.
A continuación, es posible que desees integrar Prettier en tu editor favorito. Lea la sección sobre Integración del editor en la página Prettier GitHub.
<title>
Puede encontrar el archivo HTML fuente en la carpeta public
del proyecto generado. Puede editar la etiqueta <title>
para cambiar el título de "Aplicación React" a cualquier otra cosa.
Tenga en cuenta que normalmente no editaría archivos en la carpeta public
con mucha frecuencia. Por ejemplo, agregar una hoja de estilo se realiza sin tocar el HTML.
Si necesita actualizar dinámicamente el título de la página según el contenido, puede utilizar la API document.title
del navegador. Para escenarios más complejos cuando desee cambiar el título de los componentes de React, puede usar React Helmet, una biblioteca de terceros.
Si utiliza un servidor personalizado para su aplicación en producción y desea modificar el título antes de enviarlo al navegador, puede seguir los consejos de esta sección. Alternativamente, puede crear previamente cada página como un archivo HTML estático que luego carga el paquete JavaScript, que se trata aquí.
El proyecto generado incluye React y ReactDOM como dependencias. También incluye un conjunto de scripts utilizados por la aplicación Create React como dependencia de desarrollo. Puedes instalar otras dependencias (por ejemplo, React Router) con npm
:
npm install --save react-router
Alternativamente puedes usar yarn
:
yarn add react-router
Esto funciona para cualquier biblioteca, no solo react-router
.
La configuración de este proyecto admite módulos ES6 gracias a Babel.
Si bien aún puedes usar require()
y module.exports
, te recomendamos que uses import
y export
en su lugar.
Por ejemplo:
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 ;
Tenga en cuenta la diferencia entre exportaciones predeterminadas y con nombre. Es una fuente común de errores.
Le sugerimos que siga utilizando importaciones y exportaciones predeterminadas cuando un módulo solo exporta una sola cosa (por ejemplo, un componente). Eso es lo que obtienes cuando usas export default Button
e import Button from './Button'
.
Las exportaciones con nombre son útiles para módulos de utilidades que exportan varias funciones. Un módulo puede tener como máximo una exportación predeterminada y tantas exportaciones con nombre como desee.
Obtenga más información sobre los módulos ES6:
En lugar de descargar la aplicación completa antes de que los usuarios puedan usarla, la división de código le permite dividir su código en pequeños fragmentos que luego puede cargar a pedido.
La configuración de este proyecto admite la división de código mediante import()
. Su propuesta se encuentra en la etapa 3. La forma similar a la función import()
toma el nombre del módulo como argumento y devuelve una Promise
que siempre se resuelve en el objeto de espacio de nombres del módulo.
Aquí hay un ejemplo:
moduleA.js
const moduleA = 'Hello' ;
export { moduleA } ;
App.js
import React , { Component } from 'react' ;
class App extends Component {
handleClick = ( ) => {
import ( './moduleA' )
. then ( ( { moduleA } ) => {
// Use moduleA
} )
. catch ( err => {
// Handle failure
} ) ;
} ;
render ( ) {
return (
< div >
< button onClick = { this . handleClick } > Load </ button >
</ div >
) ;
}
}
export default App ;
Esto hará que moduleA.js
y todas sus dependencias únicas sean un fragmento separado que solo se carga después de que el usuario haga clic en el botón "Cargar".
También puedes usarlo con sintaxis async
/ await
si lo prefieres.
Si está utilizando React Router, consulte este tutorial sobre cómo utilizar la división de código con él. Puede encontrar el repositorio complementario de GitHub aquí.
Consulte también la sección División de código en la documentación de React.
La configuración de este proyecto utiliza Webpack para manejar todos los activos. Webpack ofrece una forma personalizada de "extender" el concepto de import
más allá de JavaScript. Para expresar que un archivo JavaScript depende de un archivo CSS, debe importar el CSS desde el archivo JavaScript :
Button.css
. Button {
padding : 20 px ;
}
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" /> ;
}
}
Esto no es necesario para React , pero muchas personas encuentran conveniente esta función. Puede leer sobre los beneficios de este enfoque aquí. Sin embargo, debe tener en cuenta que esto hace que su código sea menos portátil que Webpack a otras herramientas y entornos de compilación.
En desarrollo, expresar dependencias de esta manera permite que sus estilos se recarguen sobre la marcha a medida que los edita. En producción, todos los archivos CSS se concatenarán en un único archivo .css
minimizado en el resultado de la compilación.
Si le preocupa utilizar la semántica específica de Webpack, puede colocar todo su CSS directamente en src/index.css
. Aún se importaría desde src/index.js
, pero siempre puedes eliminar esa importación si luego migras a una herramienta de compilación diferente.
La configuración de este proyecto minimiza su CSS y le agrega prefijos de proveedores automáticamente a través de Autoprefixer para que no tenga que preocuparse por eso.
Por ejemplo, esto:
. App {
display : flex;
flex-direction : row;
align-items : center;
}
se convierte en esto:
. 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;
}
Si necesita desactivar el prefijo automático por algún motivo, siga esta sección.
Generalmente, recomendamos no reutilizar las mismas clases CSS en diferentes componentes. Por ejemplo, en lugar de utilizar una clase CSS .Button
en los componentes <AcceptButton>
y <RejectButton>
, recomendamos crear un componente <Button>
con sus propios estilos .Button
, que tanto <AcceptButton>
como <RejectButton>
puedan representar (pero no heredar).
Seguir esta regla a menudo hace que los preprocesadores CSS sean menos útiles, ya que características como mixins y anidamiento son reemplazadas por la composición de componentes. Sin embargo, puede integrar un preprocesador CSS si lo considera valioso. En este tutorial, usaremos Sass, pero también puedes usar Less u otra alternativa.
Primero, instalemos la interfaz de línea de comandos para Sass:
npm install --save node-sass-chokidar
Alternativamente puedes usar yarn
:
yarn add node-sass-chokidar
Luego, en package.json
, agregue las siguientes líneas a scripts
:
"scripts": {
+ "build-css": "node-sass-chokidar src/ -o src/",
+ "watch-css": "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test --env=jsdom",
Nota: Para utilizar un preprocesador diferente, reemplace los comandos
build-css
ywatch-css
de acuerdo con la documentación de su preprocesador.
Ahora puede cambiar el nombre de src/App.css
a src/App.scss
y ejecutar npm run watch-css
. El observador encontrará todos los archivos Sass en los subdirectorios src
y creará un archivo CSS correspondiente junto a ellos, en nuestro caso sobrescribiendo src/App.css
. Dado que src/App.js
todavía importa src/App.css
, los estilos pasan a formar parte de su aplicación. Ahora puede editar src/App.scss
y se regenerará src/App.css
.
Para compartir variables entre archivos Sass, puede utilizar las importaciones de Sass. Por ejemplo, src/App.scss
y otros archivos de estilo de componentes podrían incluir @import "./shared.scss";
con definiciones variables.
Para habilitar la importación de archivos sin utilizar rutas relativas, puede agregar la opción --include-path
al comando en package.json
.
"build-css": "node-sass-chokidar --include-path ./src --include-path ./node_modules src/ -o src/",
"watch-css": "npm run build-css && node-sass-chokidar --include-path ./src --include-path ./node_modules src/ -o src/ --watch --recursive",
Esto le permitirá realizar importaciones como
@import ' styles/_colors.scss ' ; // assuming a styles directory under src/
@import ' nprogress/nprogress ' ; // importing a css file from the nprogress node module
En este punto, es posible que desees eliminar todos los archivos CSS del control de código fuente y agregar src/**/*.css
a tu archivo .gitignore
. Generalmente es una buena práctica mantener los productos de compilación fuera del control de código fuente.
Como paso final, puede que le resulte conveniente ejecutar watch-css
automáticamente con npm start
y ejecutar build-css
como parte de npm run build
. Puede utilizar el operador &&
para ejecutar dos scripts secuencialmente. Sin embargo, no existe una forma multiplataforma de ejecutar dos scripts en paralelo, por lo que instalaremos un paquete para esto:
npm install --save npm-run-all
Alternativamente puedes usar yarn
:
yarn add npm-run-all
Luego podemos cambiar los scripts start
y build
para incluir los comandos del preprocesador CSS:
"scripts": {
"build-css": "node-sass-chokidar src/ -o src/",
"watch-css": "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",
- "start": "react-scripts start",
- "build": "react-scripts build",
+ "start-js": "react-scripts start",
+ "start": "npm-run-all -p watch-css start-js",
+ "build-js": "react-scripts build",
+ "build": "npm-run-all build-css build-js",
"test": "react-scripts test --env=jsdom",
"eject": "react-scripts eject"
}
Ahora, al ejecutar npm start
y npm run build
también se crean archivos Sass.
¿Por qué node-sass-chokidar
?
Se ha informado que node-sass
tiene los siguientes problemas:
Se ha informado que node-sass --watch
tiene problemas de rendimiento en ciertas condiciones cuando se usa en una máquina virtual o con Docker.
Estilos infinitos recopilando #1939
Se ha informado que node-sass
tiene problemas para detectar nuevos archivos en un directorio #1891
node-sass-chokidar
se utiliza aquí porque aborda estos problemas.
Con Webpack, el uso de recursos estáticos como imágenes y fuentes funciona de manera similar a CSS.
Puede import
un archivo directamente en un módulo de JavaScript . Esto le indica a Webpack que incluya ese archivo en el paquete. A diferencia de las importaciones de CSS, la importación de un archivo le proporciona un valor de cadena. Este valor es la ruta final a la que puede hacer referencia en su código, por ejemplo, como el atributo src
de una imagen o el href
de un enlace a un PDF.
Para reducir la cantidad de solicitudes al servidor, la importación de imágenes de menos de 10.000 bytes devuelve un URI de datos en lugar de una ruta. Esto se aplica a las siguientes extensiones de archivo: bmp, gif, jpg, jpeg y png. Los archivos SVG están excluidos debido al n.° 1153.
Aquí hay un ejemplo:
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 Header ;
Esto garantiza que cuando se cree el proyecto, Webpack moverá correctamente las imágenes a la carpeta de compilación y nos proporcionará las rutas correctas.
Esto también funciona en CSS:
. Logo {
background-image : url (. / logo.png);
}
Webpack encuentra todas las referencias relativas a módulos en CSS (comienzan con ./
) y las reemplaza con las rutas finales del paquete compilado. Si comete un error tipográfico o elimina accidentalmente un archivo importante, verá un error de compilación, como cuando importa un módulo JavaScript inexistente. Webpack genera los nombres de archivo finales en el paquete compilado a partir de hashes de contenido. Si el contenido del archivo cambia en el futuro, Webpack le dará un nombre diferente en producción, por lo que no tendrá que preocuparse por el almacenamiento en caché de activos a largo plazo.
Tenga en cuenta que esta también es una característica personalizada de Webpack.
No es necesario para React , pero mucha gente lo disfruta (y React Native utiliza un mecanismo similar para las imágenes).
En la siguiente sección se describe una forma alternativa de manejar activos estáticos.
public
Nota: esta función está disponible con
[email protected]
y superior.
La carpeta public
contiene el archivo HTML para que pueda modificarlo, por ejemplo, para establecer el título de la página. La etiqueta <script>
con el código compilado se agregará automáticamente durante el proceso de compilación.
También puede agregar otros recursos a la carpeta public
.
Tenga en cuenta que normalmente le recomendamos que import
recursos en archivos JavaScript. Por ejemplo, consulte las secciones sobre cómo agregar una hoja de estilo y cómo agregar imágenes y fuentes. Este mecanismo proporciona una serie de beneficios:
Sin embargo, hay una trampilla de escape que puede utilizar para agregar un activo fuera del sistema de módulos.
Si coloca un archivo en la carpeta public
, Webpack no lo procesará. En su lugar, se copiará intacto en la carpeta de compilación. Para hacer referencia a activos en la carpeta public
, debe utilizar una variable especial llamada PUBLIC_URL
.
Dentro de index.html
, puedes usarlo así:
< link rel =" shortcut icon " href =" %PUBLIC_URL%/favicon.ico " >
Solo se podrá acceder a los archivos dentro de la carpeta public
con el prefijo %PUBLIC_URL%
. Si necesita utilizar un archivo de src
o node_modules
, tendrá que copiarlo allí para especificar explícitamente su intención de hacer que este archivo forme parte de la compilación.
Cuando ejecuta npm run build
, la aplicación Create React sustituirá %PUBLIC_URL%
con una ruta absoluta correcta para que su proyecto funcione incluso si usa enrutamiento del lado del cliente o lo aloja en una URL no raíz.
En código JavaScript, puedes usar process.env.PUBLIC_URL
para propósitos similares:
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' } /> ;
}
Tenga en cuenta las desventajas de este enfoque:
public
se posprocesa ni se minimiza.public
Normalmente recomendamos importar hojas de estilo, imágenes y fuentes desde JavaScript. La carpeta public
es útil como solución alternativa para varios casos menos comunes:
manifest.webmanifest
.pace.js
fuera del código incluido.<script>
. Tenga en cuenta que si agrega un <script>
que declara variables globales, también deberá leer la siguiente sección sobre su uso.
Cuando incluye un script en el archivo HTML que define variables globales e intenta usar una de estas variables en el código, el linter se quejará porque no puede ver la definición de la variable.
Puedes evitar esto leyendo la variable global explícitamente desde el objeto window
, por ejemplo:
const $ = window . $ ;
Esto hace que sea obvio que está utilizando una variable global intencionalmente y no debido a un error tipográfico.
Alternativamente, puede forzar al linter a ignorar cualquier línea agregando // eslint-disable-line
después.
No es necesario usar React Bootstrap junto con React, pero es una biblioteca popular para integrar Bootstrap con aplicaciones de React. Si lo necesita, puede integrarlo con la aplicación Create React siguiendo estos pasos:
Instale React Bootstrap y Bootstrap desde npm. React Bootstrap no incluye Bootstrap CSS, por lo que también es necesario instalarlo:
npm install --save react-bootstrap bootstrap@3
Alternativamente puedes usar yarn
:
yarn add react-bootstrap bootstrap@3
Importe CSS Bootstrap y, opcionalmente, CSS del tema Bootstrap al principio de su archivo src/index.js
:
import 'bootstrap/dist/css/bootstrap.css' ;
import 'bootstrap/dist/css/bootstrap-theme.css' ;
// Put any other imports below so that CSS from your
// components takes precedence over default styles.
Importe los componentes requeridos de React Bootstrap dentro del archivo src/App.js
o sus archivos de componentes personalizados:
import { Navbar , Jumbotron , Button } from 'react-bootstrap' ;
Ahora está listo para usar los componentes importados de React Bootstrap dentro de su jerarquía de componentes definida en el método de renderizado. Aquí hay un ejemplo de App.js
rehecho usando React Bootstrap.
A veces es posible que necesites modificar los estilos visuales de Bootstrap (o paquete equivalente).
Sugerimos el siguiente enfoque:
A continuación se muestra un ejemplo de cómo agregar un Bootstrap personalizado que sigue estos pasos.
Flow es un verificador de tipo estático que te ayuda a escribir código con menos errores. Consulte esta introducción al uso de tipos estáticos en JavaScript si es nuevo en este concepto.
Las versiones recientes de Flow funcionan con proyectos de la aplicación Create React listos para usar.
Para agregar Flow a un proyecto de aplicación Create React, siga estos pasos:
npm install --save flow-bin
(o yarn add flow-bin
)."flow": "flow"
a la sección scripts
de su package.json
.npm run flow init
(o yarn flow init
) para crear un archivo .flowconfig
en el directorio raíz.// @flow
a cualquier archivo que desee verificar (por ejemplo, a src/App.js
). Ahora puede ejecutar npm run flow
(o yarn flow
) para comprobar si hay errores de tipo en los archivos. Opcionalmente, puede utilizar un IDE como Nuclide para una mejor experiencia integrada. En el futuro planeamos integrarlo aún más estrechamente en la aplicación Create React.
Para obtener más información sobre Flow, consulte su documentación.
La aplicación Create React no prescribe una solución de enrutamiento específica, pero React Router es la más popular.
Para agregarlo, ejecute:
npm install --save react-router-dom
Alternativamente puedes usar yarn
:
yarn add react-router-dom
Para probarlo, elimina todo el código en src/App.js
y reemplázalo con cualquiera de los ejemplos en su sitio web. El ejemplo básico es un buen punto de partida.
Tenga en cuenta que es posible que deba configurar su servidor de producción para admitir el enrutamiento del lado del cliente antes de implementar su aplicación.
Nota: esta función está disponible con
[email protected]
y superior.
Su proyecto puede consumir variables declaradas en su entorno como si estuvieran declaradas localmente en sus archivos JS. De forma predeterminada, tendrá NODE_ENV
definido para usted y cualquier otra variable de entorno que comience con REACT_APP_
.
Las variables de entorno se integran durante el tiempo de construcción . Dado que la aplicación Create React produce un paquete HTML/CSS/JS estático, no es posible leerlos en tiempo de ejecución. Para leerlos en tiempo de ejecución, deberá cargar HTML en la memoria del servidor y reemplazar los marcadores de posición en tiempo de ejecución, tal como se describe aquí. Alternativamente, puede reconstruir la aplicación en el servidor cada vez que la cambie.
Nota: Debe crear variables de entorno personalizadas que comiencen con
REACT_APP_
. Cualquier otra variable exceptoNODE_ENV
se ignorará para evitar exponer accidentalmente una clave privada en la máquina que podría tener el mismo nombre. Cambiar cualquier variable de entorno requerirá que reinicie el servidor de desarrollo si se está ejecutando.
Estas variables de entorno se definirán para usted en process.env
. Por ejemplo, tener una variable de entorno llamada REACT_APP_SECRET_CODE
se expondrá en su JS como process.env.REACT_APP_SECRET_CODE
.
También hay una variable de entorno incorporada especial llamada NODE_ENV
. Puedes leerlo desde process.env.NODE_ENV
. Cuando ejecuta npm start
, siempre es igual a 'development'
, cuando ejecuta npm test
siempre es igual a 'test'
y cuando ejecuta npm run build
para crear un paquete de producción, siempre es igual a 'production'
. No puede anular NODE_ENV
manualmente. Esto evita que los desarrolladores implementen accidentalmente una compilación de desarrollo lento en producción.
Estas variables de entorno pueden resultar útiles para mostrar información de forma condicional en función de dónde se implementa el proyecto o consumir datos confidenciales que se encuentran fuera del control de versiones.
Primero, debe tener definidas las variables de entorno. Por ejemplo, digamos que desea consumir un secreto definido en el entorno dentro de un <form>
:
render ( ) {
return (
< div >
< small > You are running this application in < b > { process . env . NODE_ENV } </ b > mode. </ small >
< form >
< input type = "hidden" defaultValue = { process . env . REACT_APP_SECRET_CODE } />
</ form >
</ div >
) ;
}
Durante la compilación, process.env.REACT_APP_SECRET_CODE
se reemplazará con el valor actual de la variable de entorno REACT_APP_SECRET_CODE
. Recuerde que la variable NODE_ENV
se configurará automáticamente.
Cuando carga la aplicación en el navegador e inspecciona <input>
, verá su valor establecido en abcdef
y el texto en negrita mostrará el entorno proporcionado al usar npm start
:
< div >
< small > You are running this application in < b > development </ b > mode. </ small >
< form >
< input type =" hidden " value =" abcdef " />
</ form >
</ div >
El formulario anterior busca una variable llamada REACT_APP_SECRET_CODE
del entorno. Para consumir este valor, necesitamos tenerlo definido en el entorno. Esto se puede hacer de dos maneras: ya sea en su shell o en un archivo .env
. Ambas formas se describen en las siguientes secciones.
Tener acceso a NODE_ENV
también es útil para realizar acciones de forma condicional:
if ( process . env . NODE_ENV !== 'production' ) {
analytics . disable ( ) ;
}
Cuando compilas la aplicación con npm run build
, el paso de minificación eliminará esta condición y el paquete resultante será más pequeño.
Nota: esta función está disponible con
[email protected]
y superior.
También puede acceder a las variables de entorno que comienzan con REACT_APP_
en public/index.html
. Por ejemplo:
< title > %REACT_APP_WEBSITE_NAME% </ title >
Tenga en cuenta que se aplican las advertencias de la sección anterior:
NODE_ENV
y PUBLIC_URL
), los nombres de las variables deben comenzar con REACT_APP_
para funcionar.La definición de variables de entorno puede variar entre sistemas operativos. También es importante saber que esta manera es temporal durante la vida de la sesión de shell.
set " REACT_APP_SECRET_CODE = abcdef " && npm start
(Nota: se requieren comillas alrededor de la asignación de variables para evitar espacios en blanco al final).
( $ env: REACT_APP_SECRET_CODE = " abcdef " ) -and (npm start)
REACT_APP_SECRET_CODE=abcdef npm start
.env
Nota: esta función está disponible con
[email protected]
y superior.
Para definir variables de entorno permanentes, cree un archivo llamado .env
en la raíz de su proyecto:
REACT_APP_SECRET_CODE=abcdef
Nota: Debe crear variables de entorno personalizadas que comiencen con
REACT_APP_
. Cualquier otra variable exceptoNODE_ENV
se ignorará para evitar exponer accidentalmente una clave privada en la máquina que podría tener el mismo nombre. Cambiar cualquier variable de entorno requerirá que reinicie el servidor de desarrollo si se está ejecutando.
Los archivos .env
deben registrarse en el control de código fuente (con la exclusión de .env*.local
).
.env
se pueden utilizar?Nota: esta función está disponible con
[email protected]
y superior .
.env
: predeterminado..env.local
: anulaciones locales. Este archivo se carga para todos los entornos excepto el de prueba..env.development
, .env.test
, .env.production
: configuraciones específicas del entorno..env.development.local
, .env.test.local
, .env.production.local
: anulaciones locales de configuraciones específicas del entorno.Los archivos de la izquierda tienen más prioridad que los archivos de la derecha:
npm start
: .env.development.local
, .env.development
, .env.local
, .env
npm run build
: .env.production.local
, .env.production
, .env.local
, .env
npm test
: .env.test.local
, .env.test
, .env
(nota que falta .env.local
) Estas variables actuarán como predeterminadas si la máquina no las establece explícitamente.
Consulte la documentación de Dotenv para obtener más detalles.
Nota: Si está definiendo las variables de entorno para el desarrollo, su CI y/o plataforma de alojamiento probablemente también necesitarán. Consulte su documentación sobre cómo hacer esto. Por ejemplo, vea la documentación de Travis CI o Heroku.
.env
Nota: Esta característica está disponible con
[email protected]
y superior.
Expanda las variables ya en su máquina para usar en su archivo .env
(usando dotenv-expand).
Por ejemplo, para obtener la variable de entorno npm_package_version
:
REACT_APP_VERSION=$npm_package_version
# also works:
# REACT_APP_VERSION=${npm_package_version}
O expandir las variables locales al archivo .env
actual:
DOMAIN=www.example.com
REACT_APP_FOO=$DOMAIN/foo
REACT_APP_BAR=$DOMAIN/bar
Muchas bibliotecas populares utilizan decoradores en su documentación.
Crear aplicación React no admite la sintaxis del decorador en este momento porque:
Sin embargo, en muchos casos puede reescribir el código basado en el decorador sin decoradores igual de bien.
Consulte estos dos hilos como referencia:
Crear aplicación React agregará soporte del decorador cuando la especificación avance a una etapa estable.
React no prescribe un enfoque específico para la obtención de datos, pero las personas comúnmente usan una biblioteca como Axios o la API fetch()
proporcionada por el navegador. Convenientemente, Crear aplicación React incluye un polyfill para fetch()
para que pueda usarlo sin preocuparse por el soporte del navegador.
La función fetch
global permite realizar fácilmente solicitudes de AJAX. Toma una URL como una entrada y devuelve una Promise
que se resuelve a un objeto Response
. Puede encontrar más información sobre fetch
aquí.
Este proyecto también incluye un Polyfill Polyfill que proporciona una implementación completa de Promeses/A+. Una promesa representa el resultado eventual de una operación asincrónica, puede encontrar más información sobre las promesas aquí y aquí. Tanto Axios como fetch()
usan promesas debajo del capó. También puede usar la sintaxis async / await
para reducir la anidación de la devolución de llamada.
Puede obtener más información sobre cómo hacer solicitudes AJAX de los componentes React en la entrada de preguntas frecuentes en el sitio web React.
Estos tutoriales lo ayudarán a integrar su aplicación con un backend de API que se ejecuta en otro puerto, usando fetch()
para acceder a ella.
Mira este tutorial. Puede encontrar el repositorio complementario de GitHub aquí.
Mira este tutorial. Puede encontrar el repositorio complementario de GitHub aquí.
Nota: Esta característica está disponible con
[email protected]
y superior.
Las personas a menudo sirven a la aplicación React front-end del mismo host y puerto que su implementación de backend.
Por ejemplo, una configuración de producción puede verse así después de implementar la aplicación:
/ - 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
No se requiere dicha configuración. Sin embargo, si tiene una configuración como esta, es conveniente escribir solicitudes como fetch('/api/todos')
sin preocuparse por redirigirlas a otro host o puerto durante el desarrollo.
Para decirle al servidor de desarrollo que produzca cualquier solicitud desconocida a su servidor API en desarrollo, agregue un campo proxy
a su package.json
, por ejemplo:
"proxy" : "http://localhost:4000" ,
De esta manera, cuando fetch('/api/todos')
en el desarrollo, el servidor de desarrollo reconocerá que no es un activo estático, y representará su solicitud a http://localhost:4000/api/todos
como fallas. El servidor de desarrollo solo intentará enviar solicitudes sin text/html
en su encabezado Accept
al proxy.
Convenientemente, esto evita problemas de CORS y mensajes de error como este en el desarrollo:
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.
Tenga en cuenta que proxy
solo tiene efecto en el desarrollo (con npm start
), y depende de usted asegurarse de que las URL como /api/todos
apunten a lo correcto en la producción. No tiene que usar el prefijo /api
. Cualquier solicitud no reconocida sin un encabezado de aceptación text/html
se redirigirá al proxy
especificado.
La opción proxy
admite las conexiones HTTP, HTTPS y WebSocket.
Si la opción proxy
no es lo suficientemente flexible para usted, alternativamente puede:
Cuando habilita la opción proxy
, opta por un conjunto más estricto de verificaciones de host. Esto es necesario porque dejar el backend abierto a hosts remotos hace que su computadora sea vulnerable a los ataques de reembolso de DNS. El problema se explica en este artículo y en este problema.
Esto no debería afectarlo cuando se desarrolle en localhost
, pero si se desarrolla remotamente como se describe aquí, verá este error en el navegador después de habilitar la opción proxy
:
Encabezado del anfitrión no válido
Para trabajar en torno a él, puede especificar su host de desarrollo público en un archivo llamado .env.development
en la raíz de su proyecto:
HOST=mypublicdevhost.com
Si reinicia el servidor de desarrollo ahora y carga la aplicación desde el host especificado, debería funcionar.
Si todavía tiene problemas o si está utilizando un entorno más exótico como un editor en la nube, puede evitar la verificación del host agregando una línea a .env.development.local
. Tenga en cuenta que esto es peligroso y expone su máquina a la ejecución de código remoto desde sitios web maliciosos:
# NOTE: THIS IS DANGEROUS!
# It exposes your machine to attacks from the websites you visit.
DANGEROUSLY_DISABLE_HOST_CHECK=true
No recomendamos este enfoque.
Nota: Esta característica está disponible con
[email protected]
y superior.
Si la opción proxy
no es lo suficientemente flexible para usted, puede especificar un objeto en el siguiente formulario (en package.json
).
También puede especificar cualquier valor de configuración http-proxy-middleware
o http-proxy
admite.
{
// ...
"proxy" : {
"/api" : {
"target" : "<url>" ,
"ws" : true
// ...
}
}
// ...
}
Todas las solicitudes que coinciden con esta ruta serán proxies, sin excepciones. Esto incluye solicitudes de text/html
, que la opción proxy
estándar no es proxy.
Si necesita especificar múltiples proxies, puede hacerlo especificando entradas adicionales. Las coincidencias son expresiones regulares, por lo que puede usar una regexp para que coincida con múltiples rutas.
{
// ...
"proxy" : {
// Matches any request starting with /api
"/api" : {
"target" : "<url_1>" ,
"ws" : true
// ...
} ,
// Matches any request starting with /foo
"/foo" : {
"target" : "<url_2>" ,
"ssl" : true ,
"pathRewrite" : {
"^/foo" : "/foo/beta"
}
// ...
} ,
// Matches /bar/abc.html but not /bar/sub/def.html
"/bar/[^/]*[.]html" : {
"target" : "<url_3>" ,
// ...
} ,
// Matches /baz/abc.html and /baz/sub/def.html
"/baz/.*/.*[.]html" : {
"target" : "<url_4>"
// ...
}
}
// ...
}
Al configurar un proxy de WebSocket, hay algunas consideraciones adicionales a tener en cuenta.
Si está utilizando un motor WebSocket como Socket.io, debe tener un servidor Socket.io que se ejecute que puede usar como objetivo proxy. Socket.io no funcionará con un servidor WebSocket estándar. Específicamente, no espere que Socket.io funcione con la prueba de eco de WebSocket.org.
Hay una buena documentación disponible para configurar un servidor Socket.io.
WebSockets estándar funcionará con un servidor WebSocket estándar, así como con la prueba de eco de WebSocket.org. Puede usar bibliotecas como WS para el servidor, con WebSockets nativos en el navegador.
De cualquier manera, puede proxy de solicitudes de WebSocket manualmente en package.json
:
{
// ...
"proxy" : {
"/socket" : {
// Your compatible WebSocket server
"target" : "ws://<socket_url>" ,
// Tell http-proxy-middleware that this is a WebSocket proxy.
// Also allows you to proxy WebSocket requests without an additional HTTP request
// https://github.com/chimurai/http-proxy-middleware#external-websocket-upgrade
"ws" : true
// ...
}
}
// ...
}
Nota: Esta característica está disponible con
[email protected]
y superior.
Puede necesitar que el servidor Dev sirva páginas a través de HTTPS. Un caso particular en el que esto podría ser útil es cuando se usa la función "proxy" para las solicitudes de proxy a un servidor API cuando ese servidor API sirve HTTPS.
Para hacer esto, establezca la variable de entorno HTTPS
en true
, luego inicie el servidor de desarrollo como de costumbre con npm start
:
set HTTPS = true && npm start
( $ env: HTTPS = $true ) -and (npm start)
(Nota: la falta de espacio en blanco es intencional).
HTTPS=true npm start
Tenga en cuenta que el servidor usará un certificado autofirmado, por lo que su navegador web casi definitivamente mostrará una advertencia al acceder a la página.
<meta>
en el servidor Dado que Crear aplicación React no admite la representación del servidor, es posible que se pregunte cómo hacer que las etiquetas <meta>
sean dinámicas y reflejar la URL actual. Para resolver esto, recomendamos agregar marcadores de posición al HTML, como este:
<!doctype html >
< html lang =" en " >
< head >
< meta property =" og:title " content =" __OG_TITLE__ " >
< meta property =" og:description " content =" __OG_DESCRIPTION__ " >
Luego, en el servidor, independientemente del backend que use, puede leer index.html
en la memoria y reemplazar __OG_TITLE__
, __OG_DESCRIPTION__
y cualquier otro marcador de posición con valores dependiendo de la URL actual. ¡Solo asegúrese de desinfectar y escapar de los valores interpolados para que sean seguros para incrustarse en HTML!
Si usa un servidor de nodo, incluso puede compartir la lógica de coincidencia de ruta entre el cliente y el servidor. Sin embargo, duplicarlo también funciona bien en casos simples.
Si está alojando su build
con un proveedor de alojamiento estático, puede usar react-snapshot o react-snap para generar páginas HTML para cada ruta, o enlace relativo, en su aplicación. Estas páginas se volverán activas o "hidratadas" sin problemas, cuando el paquete JavaScript se haya cargado.
También hay oportunidades para usar esto fuera del alojamiento estático, para quitar la presión del servidor al generar y almacenar en caché las rutas.
El beneficio principal de la pre-renderización es que obtiene el contenido central de cada página con la carga útil HTML, independientemente de si su paquete JavaScript se descarga con éxito o no. También aumenta la probabilidad de que cada ruta de su aplicación sea recogida por los motores de búsqueda.
Puede leer más sobre la pre-renderización de la configuración cero (también llamada instantánea) aquí.
De manera similar a la sección anterior, puede dejar a algunos marcadores de posición en el HTML que inyectan variables globales, por ejemplo:
< ! doctype html >
< html lang = "en" >
< head >
< script >
window.SERVER_DATA = __SERVER_DATA__;
</ script >
Luego, en el servidor, puede reemplazar __SERVER_DATA__
con un JSON de datos reales justo antes de enviar la respuesta. El código del cliente puede leer window.SERVER_DATA
para usarlo. Asegúrese de desinfectar el JSON antes de enviarlo al cliente, ya que hace que su aplicación sea vulnerable a los ataques XSS.
Nota: Esta característica está disponible con
[email protected]
y superior.
¡Lea la Guía de migración para aprender cómo habilitarla en proyectos más antiguos!
Crear aplicación React usa Jest como su corredor de prueba. Para prepararnos para esta integración, hicimos una renovación importante de la broma, así que si escuchaste cosas malas hace años, pruébalo otro intento.
Jest es un corredor basado en el nodo. Esto significa que las pruebas siempre se ejecutan en un entorno de nodo y no en un navegador real. Esto nos permite habilitar la rápida velocidad de iteración y prevenir escamosos.
Si bien Jest proporciona globales del navegador como window
gracias a JSDOM, son solo aproximaciones del comportamiento real del navegador. Jest está destinado a usarse para pruebas unitarias de su lógica y sus componentes en lugar de las peculiaridades DOM.
Le recomendamos que use una herramienta separada para las pruebas de extremo a extremo del navegador si las necesita. Están más allá del alcance de Crear aplicación React.
Jest buscará archivos de prueba con cualquiera de las siguientes convenciones de nombres populares:
.js
en carpetas __tests__
..test.js
..spec.js
. Los archivos .test.js
/ .spec.js
(o las carpetas __tests__
) se pueden ubicar a cualquier profundidad debajo de la carpeta de nivel superior src
.
Recomendamos colocar los archivos de prueba (o __tests__
carpetas) junto al código que están probando para que las importaciones relativas parezcan más cortas. Por ejemplo, si App.test.js
y App.js
están en la misma carpeta, la prueba solo necesita import App from './App'
en lugar de una ruta relativa larga. La colocación también ayuda a encontrar pruebas más rápidamente en proyectos más grandes.
Cuando ejecuta npm test
, Jest se lanzará en el modo de reloj. Cada vez que guarde un archivo, volverá a ejecutar las pruebas, al igual que npm start
recompila el código.
El observador incluye una interfaz de línea de comandos interactiva con la capacidad de ejecutar todas las pruebas o centrarse en un patrón de búsqueda. Está diseñado de esta manera para que pueda mantenerlo abierto y disfrutar de las vueltas rápidas. Puede aprender los comandos del "Uso de reloj" Tenga en cuenta que el observador imprime después de cada ejecución:
Por defecto, cuando se ejecuta npm test
, Jest solo ejecutará las pruebas relacionadas con los archivos cambiados desde la última confirmación. Esta es una optimización diseñada para hacer que sus pruebas funcionen rápidamente, independientemente de cuántas pruebas tenga. Sin embargo, supone que a menudo no comete el código que no pasa las pruebas.
Jest siempre mencionará explícitamente que solo ejecutó pruebas relacionadas con los archivos cambiados desde la última confirmación. También puede presionar a
en el modo de reloj para forzar la broma a ejecutar todas las pruebas.
Jest siempre ejecutará todas las pruebas en un servidor de integración continuo o si el proyecto no está dentro de un repositorio GIT o Mercurial.
Para crear pruebas, agregue it()
(o test()
) bloques con el nombre de la prueba y su código. Opcionalmente, puede envolverlos en bloques describe()
para agrupación lógica, pero esto no es requerido ni recomendado.
Jest proporciona una función global expect()
integrada para hacer afirmaciones. Una prueba básica podría verse así:
import sum from './sum' ;
it ( 'sums numbers' , ( ) => {
expect ( sum ( 1 , 2 ) ) . toEqual ( 3 ) ;
expect ( sum ( 2 , 2 ) ) . toEqual ( 4 ) ;
} ) ;
Todos los Matchers expect()
compatibles con Jest están ampliamente documentados aquí.
También puede usar jest.fn()
y expect(fn).toBeCalled()
crear "espías" o funciones simuladas.
Hay un amplio espectro de técnicas de prueba de componentes. Van desde una "prueba de humo" que verifica que un componente hace sin lanzar, hasta la representación y prueba poco profunda de algunos de los resultados, hasta la representación completa y prueba del ciclo de vida de los componentes y los cambios en el estado.
Diferentes proyectos eligen diferentes compensaciones de pruebas en función de la frecuencia con la que cambian los componentes y cuánta lógica contienen. Si aún no ha decidido una estrategia de prueba, le recomendamos que comience con la creación de pruebas de humo simples para sus componentes:
import React from 'react' ;
import ReactDOM from 'react-dom' ;
import App from './App' ;
it ( 'renders without crashing' , ( ) => {
const div = document . createElement ( 'div' ) ;
ReactDOM . render ( < App /> , div ) ;
} ) ;
Esta prueba monta un componente y se asegura de que no lanzara durante la representación. Las pruebas como esta proporcionan mucho valor con muy poco esfuerzo, por lo que son excelentes como punto de partida, y esta es la prueba que encontrará en src/App.test.js
.
Cuando encuentre errores causados por el cambio de componentes, obtendrá una visión más profunda de la que vale la pena probar partes en su aplicación. Este podría ser un buen momento para introducir pruebas más específicas que afirman la producción o comportamiento esperado específico.
Si desea probar los componentes de forma aislada de los componentes infantiles que renderizan, recomendamos usar la API de representación shallow()
de la enzima. Para instalarlo, ejecute:
npm install --save enzyme enzyme-adapter-react-16 react-test-renderer
Alternativamente, puede usar yarn
:
yarn add enzyme enzyme-adapter-react-16 react-test-renderer
A partir de la enzima 3, deberá instalar una enzima junto con un adaptador correspondiente a la versión de React que está utilizando. (Los ejemplos anteriores usan el adaptador para React 16.)
El adaptador también deberá configurarse en su archivo de configuración global:
src/setupTests.js
import { configure } from 'enzyme' ;
import Adapter from 'enzyme-adapter-react-16' ;
configure ( { adapter : new Adapter ( ) } ) ;
Nota: Tenga en cuenta que si decide "expulsar" antes de crear
src/setupTests.js
, el archivopackage.json
resultante no contendrá ninguna referencia. Lea aquí para aprender a agregar esto después de expulsar.
Ahora puede escribir una prueba de humo con ella:
import React from 'react' ;
import { shallow } from 'enzyme' ;
import App from './App' ;
it ( 'renders without crashing' , ( ) => {
shallow ( < App /> ) ;
} ) ;
A diferencia de la prueba de humo anterior usando ReactDOM.render()
, esta prueba solo hace que <App>
y no sea más profunda. Por ejemplo, incluso si <App>
mismo hace que se lanza un <Button>
que se lanza, esta prueba pasará. La representación superficial es excelente para las pruebas unitarias aisladas, pero es posible que desee crear algunas pruebas de representación completas para garantizar que los componentes se integren correctamente. La enzima admite una representación completa con mount()
, y también puede usarla para probar los cambios de estado y el ciclo de vida de los componentes.
Puede leer la documentación de la enzima para obtener más técnicas de prueba. La documentación de enzimas utiliza chai y sinon para las afirmaciones, pero no tiene que usarlas porque Jest proporciona expect()
y jest.fn()
para espías.
Aquí hay un ejemplo de la documentación de enzimas que afirma una salida específica, reescrita para usar Jest Matchers:
import React from 'react' ;
import { shallow } from 'enzyme' ;
import App from './App' ;
it ( 'renders welcome message' , ( ) => {
const wrapper = shallow ( < App /> ) ;
const welcome = < h2 > Welcome to React </ h2 > ;
// expect(wrapper.contains(welcome)).to.equal(true);
expect ( wrapper . contains ( welcome ) ) . toEqual ( true ) ;
} ) ;
Todos los Jest Matchers están ampliamente documentados aquí.
Sin embargo, puede usar una biblioteca de afirmación de terceros como Chai si lo desea, como se describe a continuación.
Además, puede encontrar útil la enzima de la broma para simplificar sus pruebas con Matchers legibles. El código contains
anterior se puede escribir más simplemente con la enzima de broma.
expect ( wrapper ) . toContainReact ( welcome )
Para habilitar esto, instale jest-enzyme
:
npm install --save jest-enzyme
Alternativamente, puede usar yarn
:
yarn add jest-enzyme
Importarlo en src/setupTests.js
para que sus matares estén disponibles en cada prueba:
import 'jest-enzyme' ;
Recomendamos que use expect()
para afirmaciones y jest.fn()
para espías. Si tiene problemas con ellos, presentelos contra la broma, y los solucionaremos. Tenemos la intención de seguir mejorando para reaccionar, apoyar, por ejemplo, los elementos reactos bastante impresos como JSX.
Sin embargo, si está acostumbrado a otras bibliotecas, como Chai y Sinon, o si tiene un código existente al usarlas que desea portar, puede importarlas normalmente así:
import sinon from 'sinon' ;
import { expect } from 'chai' ;
Y luego úsalos en sus pruebas como lo hacen normalmente.
Nota: Esta característica está disponible con
[email protected]
y superior.
Si su aplicación usa una API de navegador que necesita burlarse en sus pruebas o si solo necesita una configuración global antes de ejecutar sus pruebas, agregue un src/setupTests.js
a su proyecto. Se ejecutará automáticamente antes de ejecutar sus pruebas.
Por ejemplo:
src/setupTests.js
const localStorageMock = {
getItem : jest . fn ( ) ,
setItem : jest . fn ( ) ,
clear : jest . fn ( )
} ;
global . localStorage = localStorageMock
Nota: Tenga en cuenta que si decide "expulsar" antes de crear
src/setupTests.js
, el archivopackage.json
resultante no contendrá ninguna referencia, por lo que debe crear manualmente la propiedadsetupTestFrameworkScriptFile
en la configuración para jest, algo como lo siguiente:
"jest" : { // ... "setupTestFrameworkScriptFile" : "<rootDir>/src/setupTests.js" }
Puede reemplazarlo it()
con xit()
para excluir temporalmente una prueba de ser ejecutada.
Del mismo modo, fit()
le permite concentrarse en una prueba específica sin ejecutar ninguna otra prueba.
Jest tiene un reportero de cobertura integrado que funciona bien con ES6 y no requiere configuración.
Ejecutar npm test -- --coverage
(nota extra --
el medio) para incluir un informe de cobertura como este:
Tenga en cuenta que las pruebas funcionan mucho más lentamente con la cobertura, por lo que se recomienda ejecutarlo por separado de su flujo de trabajo normal.
La configuración de cobertura de Jest predeterminada se puede anular agregando cualquiera de las siguientes claves compatibles a una configuración de Jest en su paquete.json.
Anulaciones compatibles:
collectCoverageFrom
coverageReporters
coverageThreshold
snapshotSerializers
Ejemplo de paquete.json:
{
"name" : " your-package " ,
"jest" : {
"collectCoverageFrom" : [
" src/**/*.{js,jsx} " ,
" !<rootDir>/node_modules/ " ,
" !<rootDir>/path/to/dir/ "
],
"coverageThreshold" : {
"global" : {
"branches" : 90 ,
"functions" : 90 ,
"lines" : 90 ,
"statements" : 90
}
},
"coverageReporters" : [ " text " ],
"snapshotSerializers" : [ " my-serializer-module " ]
}
}
Por defecto, npm test
ejecuta el observador con CLI interactiva. Sin embargo, puede obligarlo a ejecutar pruebas una vez y finalizar el proceso estableciendo una variable de entorno llamada CI
.
Al crear una compilación de su aplicación con las advertencias de la punta npm run build
no se verifican de forma predeterminada. Al igual que npm test
, puede obligar a la compilación a realizar una verificación de advertencia de un enlace estableciendo la variable de entorno CI
. Si se encuentran advertencias, entonces la construcción falla.
Los servidores CI populares ya establecen la variable de entorno CI
de forma predeterminada, pero también puede hacerlo usted mismo:
.travis.yml
a su repositorio Git. language: node_js
node_js:
- 6
cache:
directories:
- node_modules
script:
- npm run build
- npm test
Siga este artículo para configurar CIRCLECI con un proyecto Crear aplicación React.
set CI = true && npm test
set CI = true && npm run build
(Nota: la falta de espacio en blanco es intencional).
( $ env: CI = $true ) -and (npm test)
( $ env: CI = $true ) -and (npm run build)
CI=true npm test
CI=true npm run build
El comando de prueba obligará a la broma a ejecutar pruebas una vez en lugar de lanzar el observador.
Si se encuentra haciendo esto a menudo en el desarrollo, presente un problema para contarnos sobre su caso de uso porque queremos que Watcher sea la mejor experiencia y estamos abiertos a cambiar la forma en que funciona para acomodar más flujos de trabajo.
El comando de compilación verificará las advertencias de los deladores y fallará si se encuentra alguno.
Por defecto, el package.json
del proyecto generado se ve así:
"scripts" : {
"start" : "react-scripts start" ,
"build" : "react-scripts build" ,
"test" : "react-scripts test --env=jsdom"
Si sabe que ninguna de sus pruebas depende de JSDOM, puede eliminar de manera segura --env=jsdom
, y sus pruebas se ejecutarán más rápido:
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
- "test": "react-scripts test --env=jsdom"
+ "test": "react-scripts test"
Para ayudarlo a decidirse, aquí hay una lista de API que necesitan JSDOM :
window
y document
ReactDOM.render()
TestUtils.renderIntoDocument()
(un atajo para lo anterior)mount()
en enzimaEn contraste, JSDOM no es necesario para las siguientes API:
TestUtils.createRenderer()
(Representación superficial)shallow()
en enzimaFinalmente, JSDom tampoco es necesario para las pruebas de instantáneas.
La prueba de instantánea es una característica de la broma que genera automáticamente instantáneas de texto de sus componentes y las guarda en el disco, por lo que si la salida de la interfaz de usuario cambia, se le notifica sin escribir manualmente ninguna afirmación en la salida del componente. Lea más sobre las pruebas de instantáneas.
Si usa el código Visual Studio, hay una extensión de Jest que funciona con la aplicación Crear React App. Esto proporciona muchas funciones similares a IDE mientras se usa un editor de texto: mostrar el estado de una prueba ejecutada con posibles mensajes de falla en línea, comenzar y detener el observador automáticamente y ofrecer actualizaciones de instantáneas con un solo clic.
Hay varias formas de configurar un depurador para sus pruebas de broma. Cubrimos la depuración en Chrome y Visual Studio Code.
Nota: Las pruebas de depuración requieren el nodo 8 o superior.
Agregue lo siguiente a la sección scripts
en package.json
de su proyecto.json
"scripts" : {
"test:debug" : " react-scripts --inspect-brk test --runInBand --env=jsdom "
}
Lugar debugger;
declaraciones en cualquier prueba y ejecución:
$ npm run test:debug
Esto comenzará a ejecutar sus pruebas de broma, pero se detendrá antes de ejecutar para permitir que un depurador se adhiera al proceso.
Abra lo siguiente en Chrome
about:inspect
Después de abrir ese enlace, se mostrarán las herramientas de desarrollador de Chrome. Seleccione inspect
en su proceso y se establecerá un punto de interrupción en la primera línea del script React (esto se hace simplemente para darle tiempo para abrir las herramientas del desarrollador y evitar que la broma se ejecute antes de tener tiempo para hacerlo). Haga clic en el botón que parece un botón "Reproducir" en la parte superior derecha de la pantalla para continuar la ejecución. Cuando Jest ejecute la prueba que contiene la declaración del depurador, la ejecución se detendrá y puede examinar el alcance actual y la pila de llamadas.
Nota: La opción -Runinband CLI asegura que Jest se ejecute en el mismo proceso en lugar de procesos de desove para pruebas individuales. Normalmente, Jest paraleliza las pruebas en todos los procesos, pero es difícil depurar muchos procesos al mismo tiempo.
La depuración de las pruebas de Jest es compatible con el cuadro para el código Visual Studio.
Utilice el siguiente archivo de configuración launch.json
. JSON:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug CRA Tests",
"type": "node",
"request": "launch",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/react-scripts",
"args": [
"test",
"--runInBand",
"--no-cache",
"--env=jsdom"
],
"cwd": "${workspaceRoot}",
"protocol": "inspector",
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
]
}
Por lo general, en una aplicación, tiene muchos componentes de la interfaz de usuario, y cada uno de ellos tiene muchos estados diferentes. Para un ejemplo, un componente de botón simple podría tener los siguientes estados:
Por lo general, es difícil ver estos estados sin ejecutar una aplicación de muestra o algunos ejemplos.
La aplicación Crear React no incluye ninguna herramienta para esto de forma predeterminada, pero puede agregar fácilmente el libro de cuentos para React (fuente) o React StyleGuidist (fuente) a su proyecto. Estas son herramientas de terceros que le permiten desarrollar componentes y ver todos sus estados de forma aislada de su aplicación .
También puede implementar su libro de cuentos o guía de estilo como una aplicación estática. De esta manera, todos en su equipo pueden ver y revisar diferentes estados de componentes de la interfaz de usuario sin comenzar un servidor de backend o crear una cuenta en su aplicación.
Storybook es un entorno de desarrollo para los componentes React UI. Le permite navegar por una biblioteca de componentes, ver los diferentes estados de cada componente y desarrollar y probar interactivamente componentes.
Primero, instale el siguiente paquete NPM a nivel mundial:
npm install -g @storybook/cli
Luego, ejecute el siguiente comando dentro del directorio de su aplicación:
getstorybook
Después de eso, siga las instrucciones en la pantalla.
Obtenga más información sobre React Storybook:
StyleGuidist combina una guía de estilo, donde todos sus componentes se presentan en una sola página con sus ejemplos de documentación y uso de accesorios, con un entorno para desarrollar componentes de forma aislada, similar al libro de cuentos. En StyleGuidist escribe ejemplos en Markdown, donde cada fragmento de código se representa como un patio de recreo editable en vivo.
Primero, instale StyleGuidist:
npm install --save react-styleguidist
Alternativamente, puede usar yarn
:
yarn add react-styleguidist
Luego, agregue estos scripts a su package.json
:
"scripts": {
+ "styleguide": "styleguidist server",
+ "styleguide:build": "styleguidist build",
"start": "react-scripts start",
Luego, ejecute el siguiente comando dentro del directorio de su aplicación:
npm run styleguide
Después de eso, siga las instrucciones en la pantalla.
Obtenga más información sobre React StyleGuidist:
Crear aplicación React no proporciona ninguna funcionalidad incorporada para publicar un componente a NPM. Si está listo para extraer un componente de su proyecto para que otras personas puedan usarlo, recomendamos moverlo a un directorio separado fuera de su proyecto y luego usar una herramienta como NWB para prepararlo para la publicación.
De forma predeterminada, la compilación de producción es una aplicación web progresiva completamente fuera de línea, fuera de línea.
Las aplicaciones web progresivas son más rápidas y confiables que las páginas web tradicionales, y proporcionan una experiencia móvil atractiva:
El sw-precache-webpack-plugin
está integrado en la configuración de producción, y se encargará de generar un archivo de trabajador de servicio que precoleccione automáticamente todos sus activos locales y los mantendrá actualizados a medida que implementa actualizaciones. El trabajador de servicio utilizará una estrategia de caché para manejar todas las solicitudes de activos locales, incluido el HTML inicial, asegurando que su aplicación web sea confiablemente rápida, incluso en una red lenta o poco confiable.
Si prefiere no habilitar a los trabajadores de servicio antes de su implementación de producción inicial, retire la llamada a registerServiceWorker()
de src/index.js
.
Si hubiera habilitado previamente trabajadores de servicios en su implementación de producción y ha decidido que desea deshabilitarlos para todos sus usuarios existentes, puede cambiar la llamada a registerServiceWorker()
en src/index.js
modificando primero la importación de trabajadores de servicio :
import { unregister } from './registerServiceWorker' ;
y luego llame unregister()
en su lugar. Después de que el usuario visite una página que tenga unregister()
, el trabajador del servicio se desinstalará. Tenga en cuenta que dependiendo de cómo se sirve /service-worker.js
, puede tardar hasta 24 horas en invalidar el caché.
Los trabajadores de servicios requieren HTTPS, aunque para facilitar las pruebas locales, esa política no se aplica al localhost
. Si su servidor web de producción no admite HTTPS, entonces el registro del trabajador del servicio fallará, pero el resto de su aplicación web seguirá siendo funcional.
Los trabajadores de servicios no son compatibles actualmente en todos los navegadores web. El registro de trabajadores de servicio no se intentará en los navegadores que carecen de apoyo.
El trabajador de servicio solo está habilitado en el entorno de producción, por ejemplo, la salida de la compilación de npm run build
. Se recomienda que no habilite un trabajador de servicio fuera de línea en un entorno de desarrollo, ya que puede conducir a la frustración cuando se usan los activos en caché previamente y no incluyen los últimos cambios que ha realizado localmente.
Si necesita probar a su trabajador de servicio fuera de línea local, cree la aplicación (usando npm run build
) y ejecute un servidor HTTP simple desde su directorio de compilación. Después de ejecutar el script Build, create-react-app
dará instrucciones para una forma de probar su producción de producción localmente y las instrucciones de implementación tienen instrucciones para usar otros métodos. Asegúrese de usar siempre una ventana de incógnito para evitar complicaciones con el caché de su navegador.
Si es posible, configure su entorno de producción para servir al service-worker.js
generado.js con http en caché discapacitado. Si eso no es posible, las páginas de Github, por ejemplo, no le permiten cambiar la vida útil de caché HTTP de 10 minutos predeterminada, entonces tenga en cuenta que si visita su sitio de producción y luego vuelve a visitar antes de que service-worker.js
haya expirado de su Cache HTTP, continuará obteniendo los activos de caché previamente en caché del trabajador de servicio. Si tiene una necesidad inmediata de ver su implementación de producción actualizada, realizar una refresh de cambio desactivará temporalmente al trabajador de servicios y recuperará todos los activos de la red.
Los usuarios no siempre están familiarizados con las aplicaciones web fuera de línea. Puede ser útil informar al usuario al usuario cuándo el trabajador del servicio ha terminado de poblar sus cachés (mostrando un mensaje "¡esta aplicación web funciona fuera de línea") y también hacerles saber cuándo el trabajador de servicio ha obtenido las últimas actualizaciones que estarán disponibles en el La próxima vez que cargan la página (que muestre un "nuevo contenido está disponible; actualizar". Mensaje). Mostrar estos mensajes se deja actualmente como un ejercicio para el desarrollador, pero como punto de partida, puede hacer uso de la lógica incluida en src/registerServiceWorker.js
, que demuestra qué eventos de ciclo de vida de trabajadores de servicio escuchar para detectar cada escenario, y que como predeterminado, solo registra mensajes apropiados en la consola JavaScript.
De manera predeterminada, el archivo de trabajador de servicio generado no interceptará ni almacenará en caché ningún tráfico de origen cruzado, como solicitudes de API HTTP, imágenes o incrustaciones cargadas desde un dominio diferente. Si desea utilizar una estrategia de almacenamiento en caché de tiempo de ejecución para esas solicitudes, puede eject
y luego configurar la opción runtimeCaching
en la sección SWPrecacheWebpackPlugin
de webpack.config.prod.js
.
La configuración predeterminada incluye un manifiesto de la aplicación web ubicada en public/manifest.json
, que puede personalizar con detalles específicos para su aplicación web.
Cuando un usuario agrega una aplicación web a su pantalla de inicio utilizando Chrome o Firefox en Android, los metadatos en manifest.json
determinan qué iconos, nombres y colores de marca usar cuando se muestra la aplicación web. La guía de manifiesto de la aplicación web proporciona más contexto sobre lo que significa cada campo y cómo sus personalizaciones afectarán la experiencia de sus usuarios.
El explorador de mapa de origen analiza los paquetes de JavaScript utilizando los mapas de origen. Esto le ayuda a comprender de dónde proviene el código de código.
Para agregar el explorador de mapas de origen a un proyecto Crear aplicación React, siga estos pasos:
npm install --save source-map-explorer
Alternativamente, puede usar yarn
:
yarn add source-map-explorer
Luego, en package.json
, agregue la siguiente línea a scripts
:
"scripts": {
+ "analyze": "source-map-explorer build/static/js/main.*",
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test --env=jsdom",
Luego, para analizar el paquete, ejecute la compilación de producción y luego ejecute el script de análisis.
npm run build
npm run analyze
npm run build
crea un directorio build
con una construcción de producción de su aplicación. Configure su servidor HTTP favorito para que un visitante en su sitio se sirva index.html
, y las solicitudes a rutas estáticas como /static/js/main.<hash>.js
se sirven con el contenido de /static/js/main.<hash>.js
FILE.
Para los entornos que usan Node, la forma más fácil de manejar esto sería instalar servir y dejar que maneje el resto:
npm install -g serve
serve -s build
El último comando que se muestra arriba servirá a su sitio estático en el puerto 5000 . Al igual que muchas de las configuraciones internas de Servir, el puerto se puede ajustar utilizando las banderas -p
o --port
.
Ejecute este comando para obtener una lista completa de las opciones disponibles:
serve -h
No necesariamente necesita un servidor estático para ejecutar un proyecto Crear aplicación React en producción. Funciona igual de bien integrado en una dinámica existente.
Aquí hay un ejemplo programático usando nodo y expreso:
const express = require ( 'express' ) ;
const path = require ( 'path' ) ;
const app = express ( ) ;
app . use ( express . static ( path . join ( __dirname , 'build' ) ) ) ;
app . get ( '/' , function ( req , res ) {
res . sendFile ( path . join ( __dirname , 'build' , 'index.html' ) ) ;
} ) ;
app . listen ( 9000 ) ;
La elección del software de su servidor tampoco es importante. Dado que Crear aplicación React es completamente agnóstico de la plataforma, no hay necesidad de usar nodo explícitamente.
La carpeta build
con activos estáticos es la única salida producida por la aplicación Create React.
Sin embargo, esto no es suficiente si usa el enrutamiento del lado del cliente. Lea la siguiente sección si desea admitir URL como /todos/42
en su aplicación de una sola página.
If you use routers that use the HTML5 pushState
history API under the hood (for example, React Router with browserHistory
), many static file servers will fail. For example, if you used React Router with a route for /todos/42
, the development server will respond to localhost:3000/todos/42
properly, but an Express serving a production build as above will not.
This is because when there is a fresh page load for a /todos/42
, the server looks for the file build/todos/42
and does not find it. The server needs to be configured to respond to a request to /todos/42
by serving index.html
. For example, we can amend our Express example above to serve index.html
for any unknown paths:
app.use(express.static(path.join(__dirname, 'build')));
- app.get('/', function (req, res) {
+ app.get('/*', function (req, res) {
res.sendFile(path.join(__dirname, 'build', 'index.html'));
});
If you're using Apache HTTP Server, you need to create a .htaccess
file in the public
folder that looks like this:
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]
It will get copied to the build
folder when you run npm run build
.
If you're using Apache Tomcat, you need to follow this Stack Overflow answer.
Now requests to /todos/42
will be handled correctly both in development and in production.
On a production build, and in a browser that supports service workers, the service worker will automatically handle all navigation requests, like for /todos/42
, by serving the cached copy of your index.html
. This service worker navigation routing can be configured or disabled by eject
ing and then modifying the navigateFallback
and navigateFallbackWhitelist
options of the SWPreachePlugin
configuration.
When users install your app to the homescreen of their device the default configuration will make a shortcut to /index.html
. This may not work for client-side routers which expect the app to be served from /
. Edit the web app manifest at public/manifest.json
and change start_url
to match the required URL scheme, for example:
"start_url" : "." ,
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.
Note : If you are using react-router@^4
, you can root <Link>
s using the basename
prop on any <Router>
.
Más información aquí.
Por ejemplo:
< BrowserRouter basename = "/calendar" />
< Link to = "/today" / > // renders <a href="/calendar/today">
Note: this feature is available with
[email protected]
and higher.
If you are not using the HTML5 pushState
history API or not using client-side routing at all, it is unnecessary to specify the URL from which your app will be served. Instead, you can put this in your package.json
:
"homepage" : "." ,
This will make sure that all the asset paths are relative to index.html
. You will then be able to move your app from http://mywebsite.com
to http://mywebsite.com/relativepath
or even http://mywebsite.com/relative/path
without having to rebuild it.
See this blog post on how to deploy your React app to Microsoft Azure.
See this blog post or this repo for a way to use automatic deployment to Azure App Service.
Install the Firebase CLI if you haven't already by running npm install -g firebase-tools
. Sign up for a Firebase account and create a new project. Run firebase login
and login with your previous created Firebase account.
Then run the firebase init
command from your project's root. You need to choose the Hosting: Configure and deploy Firebase Hosting sites and choose the Firebase project you created in the previous step. You will need to agree with database.rules.json
being created, choose build
as the public directory, and also agree to Configure as a single-page app by replying with y
.
=== Project Setup
First, let ' s associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,
but for now we ' ll just set up a default project.
? What Firebase project do you want to associate as default ? Example app (example-app-fd690)
=== Database Setup
Firebase Realtime Database Rules allow you to define how your data should be
structured and when your data can be read from and written to.
? What file should be used for Database Rules ? database.rules.json
✔ Database Rules for example-app-fd690 have been downloaded to database.rules.json.
Future modifications to database.rules.json will update Database Rules when you run
firebase deploy.
=== Hosting Setup
Your public directory is the folder (relative to your project directory) that
will contain Hosting assets to uploaded with firebase deploy. If you
have a build process for your assets, use your build ' s output directory.
? What do you want to use as your public directory? build
? Configure as a single-page app (rewrite all urls to /index.html)? Yes
✔ Wrote build/index.html
i Writing configuration info to firebase.json...
i Writing project information to .firebaserc...
✔ Firebase initialization complete!
IMPORTANT: you need to set proper HTTP caching headers for service-worker.js
file in firebase.json
file or you will not be able to see changes after first deployment (issue #2440). It should be added inside "hosting"
key like next:
{
"hosting": {
...
"headers": [
{"source": "/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}]}
]
...
Now, after you create a production build with npm run build
, you can deploy it by running firebase deploy
.
=== Deploying to ' example-app-fd690 ' ...
i deploying database, hosting
✔ database: rules ready to deploy.
i hosting: preparing build directory for upload...
Uploading: [ ============================== ] 75%✔ hosting: build folder uploaded successfully
✔ hosting: 8 files uploaded successfully
i starting release process (may take several minutes)...
✔ Deploy complete !
Project Console: https://console.firebase.google.com/project/example-app-fd690/overview
Hosting URL: https://example-app-fd690.firebaseapp.com
For more information see Add Firebase to your JavaScript Project.
Note: this feature is available with
[email protected]
and higher.
homepage
to package.json
The step below is important!
If you skip it, your app will not deploy correctly.
Open your package.json
and add a homepage
field for your project:
"homepage" : " https://myusername.github.io/my-app " ,
or for a GitHub user page:
"homepage" : " https://myusername.github.io " ,
Create React App uses the homepage
field to determine the root URL in the built HTML file.
gh-pages
and add deploy
to scripts
in package.json
Now, whenever you run npm run build
, you will see a cheat sheet with instructions on how to deploy to GitHub Pages.
To publish it at https://myusername.github.io/my-app, run:
npm install --save gh-pages
Alternatively you may use yarn
:
yarn add gh-pages
Add the following scripts in your package.json
:
"scripts": {
+ "predeploy": "npm run build",
+ "deploy": "gh-pages -d build",
"start": "react-scripts start",
"build": "react-scripts build",
The predeploy
script will run automatically before deploy
is run.
If you are deploying to a GitHub user page instead of a project page you'll need to make two additional modifications:
package.json
scripts to push deployments to master : "scripts": {
"predeploy": "npm run build",
- "deploy": "gh-pages -d build",
+ "deploy": "gh-pages -b master -d build",
npm run deploy
Then run:
npm run deploy
gh-pages
Finally, make sure GitHub Pages option in your GitHub project settings is set to use the gh-pages
branch:
You can configure a custom domain with GitHub Pages by adding a CNAME
file to the public/
folder.
GitHub Pages doesn't support routers that use the HTML5 pushState
history API under the hood (for example, React Router using browserHistory
). This is because when there is a fresh page load for a url like http://user.github.io/todomvc/todos/42
, where /todos/42
is a frontend route, the GitHub Pages server returns 404 because it knows nothing of /todos/42
. If you want to add a router to a project hosted on GitHub Pages, here are a couple of solutions:
hashHistory
for this effect, but the URL will be longer and more verbose (for example, http://user.github.io/todomvc/#/todos/42?_k=yknaj
) . Read more about different history implementations in React Router.index.html
page with a special redirect parameter. You would need to add a 404.html
file with the redirection code to the build
folder before deploying your project, and you'll need to add code handling the redirect parameter to index.html
. You can find a detailed explanation of this technique in this guide. Use the Heroku Buildpack for Create React App.
You can find instructions in Deploying React with Zero Configuration.
Sometimes npm run build
works locally but fails during deploy via Heroku. Following are the most common cases.
If you get something like this:
remote: Failed to create a production build. Reason:
remote: Module not found: Error: Cannot resolve 'file' or 'directory'
MyDirectory in /tmp/build_1234/src
It means you need to ensure that the lettercase of the file or directory you import
matches the one you see on your filesystem or on GitHub.
This is important because Linux (the operating system used by Heroku) is case sensitive. So MyDirectory
and mydirectory
are two distinct directories and thus, even though the project builds locally, the difference in case breaks the import
statements on Heroku remotes.
If you exclude or ignore necessary files from the package you will see a error similar this one:
remote: Could not find a required file.
remote: Name: `index.html`
remote: Searched in: /tmp/build_a2875fc163b209225122d68916f1d4df/public
remote:
remote: npm ERR! Linux 3.13.0-105-generic
remote: npm ERR! argv "/tmp/build_a2875fc163b209225122d68916f1d4df/.heroku/node/bin/node" "/tmp/build_a2875fc163b209225122d68916f1d4df/.heroku/node/bin/npm" "run" "build"
In this case, ensure that the file is there with the proper lettercase and that's not ignored on your local .gitignore
or ~/.gitignore_global
.
To do a manual deploy to Netlify's CDN:
npm install netlify-cli -g
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:
yarn build
as the build command and build
as the publish directoryDeploy 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 offers a zero-configuration single-command deployment. You can use now
to deploy your app for free.
Install the now
command-line tool either via the recommended desktop tool or via node with npm install -g now
.
Build your app by running npm run build
.
Move into the build directory by running cd build
.
Run now --name your-project-name
from within the build directory. You will see a now.sh URL in your output like this:
> Ready! https://your-project-name-tpspyhtdtk.now.sh (copied to clipboard)
Paste that URL into your browser when the build is complete, and you will see your deployed app.
Details are available in this article.
See this blog post on how to deploy your React app to Amazon Web Services S3 and CloudFront.
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.
When asked about the project path, make sure to specify the build
folder, for example:
project path: /path/to/project/build
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.
You can adjust various development and production settings by setting environment variables in your shell or with .env.
Variable | Desarrollo | Producción | Uso |
---|---|---|---|
NAVEGADOR | ✅ | By default, Create React App will open the default system browser, favoring Chrome on macOS. Specify a browser to override this behavior, or set it to none to disable it completely. If you need to customize the way the browser is launched, you can specify a node script instead. Any arguments passed to npm start will also be passed to this script, and the url where your app is served will be the last argument. Your script's file name must have the .js extension. | |
ANFITRIÓN | ✅ | By default, the development web server binds to localhost . You may use this variable to specify a different host. | |
PUERTO | ✅ | By default, the development web server will attempt to listen on port 3000 or prompt you to attempt the next available port. You may use this variable to specify a different port. | |
HTTPS | ✅ | When set to true , Create React App will run the development server in https mode. | |
PUBLIC_URL | ✅ | Create React App assumes your application is hosted at the serving web server's root or a subpath as specified in package.json ( homepage ). Normally, Create React App ignores the hostname. You may use this variable to force assets to be referenced verbatim to the url you provide (hostname included). This may be particularly useful when using a CDN to host your application. | |
CI | ? | ✅ | When set to true , Create React App treats warnings as failures in the build. It also makes the test runner non-watching. Most CIs set this flag by default. |
REACT_EDITOR | ✅ | When an app crashes in development, you will see an error overlay with clickable stack trace. When you click on it, Create React App will try to determine the editor you are using based on currently running processes, and open the relevant source file. You can send a pull request to detect your editor of choice. Setting this environment variable overrides the automatic detection. If you do it, make sure your systems PATH environment variable points to your editor's bin folder. You can also set it to none to disable it completely. | |
CHOKIDAR_USEPOLLING | ✅ | When set to true , the watcher runs in polling mode, as necessary inside a VM. Use this option if npm start isn't detecting changes. | |
GENERATE_SOURCEMAP | ✅ | When set to false , source maps are not generated for a production build. This solves OOM issues on some smaller machines. | |
NODE_PATH | ✅ | ✅ | Same as NODE_PATH in Node.js, but only relative folders are allowed. Can be handy for emulating a monorepo setup by setting NODE_PATH=src . |
npm start
doesn't detect changes When you save a file while npm start
is running, the browser should refresh with the updated code.
If this doesn't happen, try one of the following workarounds:
index.js
and you're referencing it by the folder name, you need to restart the watcher due to a Webpack bug..env
file in your project directory if it doesn't exist, and add CHOKIDAR_USEPOLLING=true
to it. This ensures that the next time you run npm start
, the watcher uses the polling mode, as necessary inside a VM.If none of these solutions help please leave a comment in this thread.
npm test
hangs on macOS Sierra If you run npm test
and the console gets stuck after printing react-scripts test --env=jsdom
to the console there might be a problem with your Watchman installation as described in facebookincubator/create-react-app#713.
We recommend deleting node_modules
in your project and running npm install
(or yarn
if you use it) first. If it doesn't help, you can try one of the numerous workarounds mentioned in these issues:
It is reported that installing Watchman 4.7.0 or newer fixes the issue. If you use Homebrew, you can run these commands to update it:
watchman shutdown-server
brew update
brew reinstall watchman
You can find other installation methods on the Watchman documentation page.
If this still doesn't help, try running launchctl unload -F ~/Library/LaunchAgents/com.github.facebook.watchman.plist
.
There are also reports that uninstalling Watchman fixes the issue. So if nothing else helps, remove it from your system and try again.
npm run build
exits too early It is reported that npm run build
can fail on machines with limited memory and no swap space, which is common in cloud environments. Even with small projects this command can increase RAM usage in your system by hundreds of megabytes, so if you have less than 1 GB of available memory your build is likely to fail with the following message:
The build failed because the process exited too early. This probably means the system ran out of memory or someone called
kill -9
on the process.
If you are completely sure that you didn't terminate the process, consider adding some swap space to the machine you're building on, or build the project locally.
npm run build
fails on HerokuThis may be a problem with case sensitive filenames. Please refer to this section.
If you use a Moment.js, you might notice that only the English locale is available by default. This is because the locale files are large, and you probably only need a subset of all the locales provided by Moment.js.
To add a specific Moment.js locale to your bundle, you need to import it explicitly.
Por ejemplo:
import moment from 'moment' ;
import 'moment/locale/fr' ;
If import multiple locales this way, you can later switch between them by calling moment.locale()
with the locale name:
import moment from 'moment' ;
import 'moment/locale/fr' ;
import 'moment/locale/es' ;
// ...
moment . locale ( 'fr' ) ;
This will only work for locales that have been explicitly imported before.
npm run build
fails to minifySome third-party packages don't compile their code to ES5 before publishing to npm. This often causes problems in the ecosystem because neither browsers (except for most modern versions) nor some tools currently support all ES6 features. We recommend to publish code on npm as ES5 at least for a few more years.
module
field in package.json
. Note that even if a library provides an ES Modules version, it should still precompile other ES6 features to ES5 if it intends to support older browsers .Fork the package and publish a corrected version yourself.
If the dependency is small enough, copy it to your src/
folder and treat it as application code.
In the future, we might start automatically compiling incompatible third-party modules, but it is not currently supported. This approach would also slow down the production builds.
Ejecting lets you customize anything, but from that point on you have to maintain the configuration and scripts yourself. This can be daunting if you have many similar projects. In such cases instead of ejecting we recommend to fork react-scripts
and any other packages you need. This article dives into how to do it in depth. You can find more discussion in this issue.
If you have ideas for more “How To” recipes that should be on this page, let us know or contribute some!