Ce projet a été démarré avec Create React App.
Vous trouverez ci-dessous quelques informations sur la manière d'effectuer les tâches courantes.
Vous pouvez trouver la version la plus récente de ce guide ici.
<title>
public
public
.env
<meta>
dynamiques sur le serveurnpm start
ne détecte pas les changementsnpm test
se bloque sur macOS Sierranpm run build
se termine trop tôtnpm run build
échoue sur Herokunpm run build
ne parvient pas à réduireCreate React App est divisé en deux packages :
create-react-app
est un utilitaire de ligne de commande global que vous utilisez pour créer de nouveaux projets.react-scripts
est une dépendance de développement dans les projets générés (y compris celui-ci). Vous n'avez presque jamais besoin de mettre à jour create-react-app
lui-même : il délègue toute la configuration à react-scripts
.
Lorsque vous exécutez create-react-app
, il crée toujours le projet avec la dernière version des react-scripts
afin que vous obteniez automatiquement toutes les nouvelles fonctionnalités et améliorations des applications nouvellement créées.
Pour mettre à jour un projet existant vers une nouvelle version de react-scripts
, ouvrez le journal des modifications, recherchez la version que vous utilisez actuellement (vérifiez package.json
dans ce dossier si vous n'êtes pas sûr) et appliquez les instructions de migration pour la version la plus récente. versions.
Dans la plupart des cas, modifier la version de react-scripts
dans package.json
et exécuter npm install
dans ce dossier devrait suffire, mais il est bon de consulter le journal des modifications pour connaître les modifications potentielles.
Nous nous engageons à maintenir les modifications majeures au minimum afin que vous puissiez mettre à niveau react-scripts
sans douleur.
Nous sommes toujours ouverts à vos commentaires.
Après création, votre projet devrait ressembler à ceci :
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
Pour que le projet soit construit, ces fichiers doivent exister avec des noms de fichiers exacts :
public/index.html
est le modèle de page ;src/index.js
est le point d'entrée JavaScript.Vous pouvez supprimer ou renommer les autres fichiers.
Vous pouvez créer des sous-répertoires dans src
. Pour des reconstructions plus rapides, seuls les fichiers contenus dans src
sont traités par Webpack.
Vous devez placer tous les fichiers JS et CSS dans src
, sinon Webpack ne les verra pas.
Seuls les fichiers public
peuvent être utilisés à partir de public/index.html
.
Lisez les instructions ci-dessous pour utiliser les ressources JavaScript et HTML.
Vous pouvez toutefois créer davantage de répertoires de niveau supérieur.
Ils ne seront pas inclus dans la version de production, vous pourrez donc les utiliser pour des choses comme la documentation.
Dans le répertoire du projet, vous pouvez exécuter :
npm start
Exécute l'application en mode développement.
Ouvrez http://localhost:3000 pour l'afficher dans le navigateur.
La page se rechargera si vous apportez des modifications.
Vous verrez également des erreurs de charpie dans la console.
npm test
Lance le testeur en mode montre interactive.
Consultez la section sur l'exécution de tests pour plus d'informations.
npm run build
Construit l'application pour la production dans le dossier build
.
Il regroupe correctement React en mode production et optimise la construction pour les meilleures performances.
La construction est réduite et les noms de fichiers incluent les hachages.
Votre application est prête à être déployée !
Consultez la section sur le déploiement pour plus d'informations.
npm run eject
Attention : il s’agit d’une opération à sens unique. Une fois eject
, vous ne pouvez plus revenir en arrière !
Si vous n'êtes pas satisfait de l'outil de construction et des choix de configuration, vous pouvez eject
à tout moment. Cette commande supprimera la dépendance de build unique de votre projet.
Au lieu de cela, il copiera tous les fichiers de configuration et les dépendances transitives (Webpack, Babel, ESLint, etc.) directement dans votre projet afin que vous en ayez le contrôle total. Toutes les commandes, à l'exception eject
fonctionneront toujours, mais elles pointeront vers les scripts copiés afin que vous puissiez les modifier. À ce stade, vous êtes seul.
Vous n’êtes jamais obligé d’utiliser eject
. L'ensemble de fonctionnalités organisé est adapté aux déploiements de petite et moyenne taille, et vous ne devriez pas vous sentir obligé d'utiliser cette fonctionnalité. Cependant, nous comprenons que cet outil ne serait pas utile si vous ne pouviez pas le personnaliser lorsque vous y êtes prêt.
Par défaut, le projet généré utilise la dernière version de React.
Vous pouvez vous référer à la documentation React pour plus d'informations sur les navigateurs pris en charge.
Ce projet prend en charge un surensemble de la dernière norme JavaScript.
En plus des fonctionnalités de syntaxe ES6, il prend également en charge :
Apprenez-en davantage sur les différentes étapes de la proposition.
Bien que nous recommandions d'utiliser les propositions expérimentales avec une certaine prudence, Facebook utilise largement ces fonctionnalités dans le code du produit. Nous avons donc l'intention de fournir des codemods si l'une de ces propositions change à l'avenir.
Notez que le projet ne comprend que quelques polyfills ES6 :
Object.assign()
via object-assign
.Promise
via promise
.fetch()
via whatwg-fetch
. Si vous utilisez d'autres fonctionnalités ES6+ nécessitant une prise en charge à l'exécution (telles que Array.from()
ou Symbol
), assurez-vous d'inclure manuellement les polyfills appropriés ou que les navigateurs que vous ciblez les prennent déjà en charge.
Notez également que l'utilisation de certaines fonctionnalités de syntaxe plus récentes telles que for...of
ou [...nonArrayValue]
amène Babel à émettre du code qui dépend des fonctionnalités d'exécution ES6 et pourrait ne pas fonctionner sans polyfill. En cas de doute, utilisez Babel REPL pour voir à quoi correspond une syntaxe spécifique.
Pour configurer la coloration syntaxique dans votre éditeur de texte préféré, rendez-vous sur la page de documentation Babel appropriée et suivez les instructions. Certains des éditeurs les plus populaires sont couverts.
Remarque : cette fonctionnalité est disponible avec
[email protected]
et versions ultérieures.
Cela ne fonctionne également qu'avec npm 3 ou supérieur.
Certains éditeurs, notamment Sublime Text, Atom et Visual Studio Code, proposent des plugins pour ESLint.
Ils ne sont pas nécessaires pour le peluchage. Vous devriez voir la sortie linter directement dans votre terminal ainsi que dans la console du navigateur. Cependant, si vous préférez que les résultats des peluches apparaissent directement dans votre éditeur, vous pouvez effectuer quelques étapes supplémentaires.
Vous devrez d'abord installer un plugin ESLint pour votre éditeur. Ensuite, ajoutez un fichier appelé .eslintrc
à la racine du projet :
{
"extends" : "react-app"
}
Votre éditeur doit maintenant signaler les avertissements de peluchage.
Notez que même si vous modifiez davantage votre fichier .eslintrc
, ces modifications n'affecteront que l'intégration de l'éditeur . Ils n’affecteront pas la sortie des peluches du terminal et du navigateur. En effet, Create React App fournit intentionnellement un ensemble minimal de règles qui détectent les erreurs courantes.
Si vous souhaitez appliquer un style de codage pour votre projet, envisagez d'utiliser Prettier au lieu des règles de style ESLint.
Cette fonctionnalité n'est actuellement prise en charge que par Visual Studio Code et WebStorm.
Visual Studio Code et WebStorm prennent en charge le débogage dès le départ avec Create React App. Cela vous permet en tant que développeur d'écrire et de déboguer votre code React sans quitter l'éditeur, et surtout, cela vous permet d'avoir un flux de travail de développement continu, où le changement de contexte est minime, car vous n'avez pas besoin de basculer entre les outils.
Vous devez avoir installé la dernière version de VS Code et de l’extension de débogueur Chrome VS Code.
Ajoutez ensuite le bloc ci-dessous à votre fichier launch.json
et placez-le dans le dossier .vscode
du répertoire racine de votre application.
{
"version" : " 0.2.0 " ,
"configurations" : [{
"name" : " Chrome " ,
"type" : " chrome " ,
"request" : " launch " ,
"url" : " http://localhost:3000 " ,
"webRoot" : " ${workspaceRoot}/src " ,
"sourceMapPathOverrides" : {
"webpack:///src/*" : " ${webRoot}/* "
}
}]
}
Remarque : l'URL peut être différente si vous avez effectué des ajustements via les variables d'environnement HOST ou PORT.
Démarrez votre application en exécutant npm start
et démarrez le débogage dans VS Code en appuyant sur F5
ou en cliquant sur l'icône de débogage verte. Vous pouvez désormais écrire du code, définir des points d'arrêt, apporter des modifications au code et déboguer votre code nouvellement modifié, le tout depuis votre éditeur.
Vous rencontrez des problèmes avec le débogage de VS Code ? Veuillez consulter leur guide de dépannage.
Vous devez avoir installé l'extension Chrome WebStorm et JetBrains IDE Support.
Dans le menu WebStorm Run
sélectionnez Edit Configurations...
. Cliquez ensuite sur +
et sélectionnez JavaScript Debug
. Collez http://localhost:3000
dans le champ URL et enregistrez la configuration.
Remarque : l'URL peut être différente si vous avez effectué des ajustements via les variables d'environnement HOST ou PORT.
Démarrez votre application en exécutant npm start
, puis appuyez sur ^D
sous macOS ou F9
sous Windows et Linux ou cliquez sur l'icône de débogage verte pour démarrer le débogage dans WebStorm.
De la même manière, vous pouvez déboguer votre application dans IntelliJ IDEA Ultimate, PhpStorm, PyCharm Pro et RubyMine.
Prettier est un formateur de code avisé prenant en charge JavaScript, CSS et JSON. Avec Prettier, vous pouvez formater automatiquement le code que vous écrivez pour garantir un style de code au sein de votre projet. Consultez la page GitHub de Prettier pour plus d'informations et consultez cette page pour la voir en action.
Pour formater notre code chaque fois que nous effectuons un commit dans git, nous devons installer les dépendances suivantes :
npm install --save husky lint-staged prettier
Alternativement, vous pouvez utiliser yarn
:
yarn add husky lint-staged prettier
husky
facilite l'utilisation des githooks comme s'il s'agissait de scripts npm.lint-staged
nous permet d'exécuter des scripts sur des fichiers préparés dans git. Consultez cet article de blog sur la mise en scène du lint pour en savoir plus.prettier
. Nous pouvons maintenant nous assurer que chaque fichier est correctement formaté en ajoutant quelques lignes au package.json
à la racine du projet.
Ajoutez la ligne suivante à la section scripts
:
"scripts": {
+ "precommit": "lint-staged",
"start": "react-scripts start",
"build": "react-scripts build",
Ensuite, nous ajoutons un champ « lint-staged » au package.json
, par exemple :
"dependencies": {
// ...
},
+ "lint-staged": {
+ "src/**/*.{js,jsx,json,css}": [
+ "prettier --single-quote --write",
+ "git add"
+ ]
+ },
"scripts": {
Désormais, chaque fois que vous effectuez une validation, Prettier formatera automatiquement les fichiers modifiés. Vous pouvez également exécuter ./node_modules/.bin/prettier --single-quote --write "src/**/*.{js,jsx,json,css}"
pour formater l'intégralité de votre projet pour la première fois.
Ensuite, vous souhaiterez peut-être intégrer Prettier dans votre éditeur préféré. Lisez la section sur l'intégration de l'éditeur sur la page Prettier GitHub.
<title>
Vous pouvez trouver le fichier HTML source dans le dossier public
du projet généré. Vous pouvez y modifier la balise <title>
pour changer le titre de « React App » en autre chose.
Notez que normalement, vous ne modifierez pas très souvent les fichiers du dossier public
. Par exemple, l’ajout d’une feuille de style se fait sans toucher au HTML.
Si vous devez mettre à jour dynamiquement le titre de la page en fonction du contenu, vous pouvez utiliser l'API document.title
du navigateur. Pour des scénarios plus complexes où vous souhaitez modifier le titre des composants React, vous pouvez utiliser React Helmet, une bibliothèque tierce.
Si vous utilisez un serveur personnalisé pour votre application en production et que vous souhaitez modifier le titre avant qu'il ne soit envoyé au navigateur, vous pouvez suivre les conseils de cette section. Alternativement, vous pouvez pré-construire chaque page sous forme de fichier HTML statique qui charge ensuite le bundle JavaScript, abordé ici.
Le projet généré inclut React et ReactDOM comme dépendances. Il comprend également un ensemble de scripts utilisés par Create React App comme dépendance de développement. Vous pouvez installer d'autres dépendances (par exemple, React Router) avec npm
:
npm install --save react-router
Alternativement, vous pouvez utiliser yarn
:
yarn add react-router
Cela fonctionne pour n'importe quelle bibliothèque, pas seulement pour react-router
.
Cette configuration de projet prend en charge les modules ES6 grâce à Babel.
Bien que vous puissiez toujours utiliser require()
et module.exports
, nous vous encourageons à utiliser import
et export
à la place.
Par exemple:
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 ;
Soyez conscient de la différence entre les exportations par défaut et nommées. C'est une source courante d'erreurs.
Nous vous suggérons de vous en tenir à l'utilisation des importations et des exportations par défaut lorsqu'un module n'exporte qu'un seul élément (par exemple, un composant). C'est ce que vous obtenez lorsque vous utilisez export default Button
et import Button from './Button'
.
Les exportations nommées sont utiles pour les modules utilitaires qui exportent plusieurs fonctions. Un module peut avoir au plus une exportation par défaut et autant d'exportations nommées que vous le souhaitez.
En savoir plus sur les modules ES6 :
Au lieu de télécharger l'intégralité de l'application avant que les utilisateurs puissent l'utiliser, le fractionnement du code vous permet de diviser votre code en petits morceaux que vous pouvez ensuite charger à la demande.
Cette configuration de projet prend en charge le fractionnement du code via Dynamic import()
. Sa proposition en est à l'étape 3. La forme semblable à une fonction import()
prend le nom du module comme argument et renvoie une Promise
qui se résout toujours en l'objet espace de noms du module.
Voici un exemple :
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 ;
Cela fera moduleA.js
et de toutes ses dépendances uniques un morceau distinct qui ne se chargera qu'après que l'utilisateur aura cliqué sur le bouton « Charger ».
Vous pouvez également l'utiliser avec la syntaxe async
/ await
si vous le préférez.
Si vous utilisez React Router, consultez ce tutoriel pour savoir comment utiliser le fractionnement de code avec celui-ci. Vous pouvez trouver le référentiel GitHub compagnon ici.
Consultez également la section Code Fractionnement dans la documentation React.
Cette configuration de projet utilise Webpack pour gérer tous les actifs. Webpack propose une manière personnalisée « d'étendre » le concept d' import
au-delà de JavaScript. Pour exprimer qu'un fichier JavaScript dépend d'un fichier CSS, vous devez importer le CSS depuis le fichier 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" /> ;
}
}
Ce n'est pas obligatoire pour React mais de nombreuses personnes trouvent cette fonctionnalité pratique. Vous pouvez en savoir plus sur les avantages de cette approche ici. Cependant, vous devez être conscient que cela rend votre code moins portable vers d'autres outils et environnements de build que Webpack.
En développement, exprimer les dépendances de cette manière permet de recharger vos styles à la volée au fur et à mesure que vous les modifiez. En production, tous les fichiers CSS seront concaténés en un seul fichier .css
minifié dans la sortie de construction.
Si vous souhaitez utiliser la sémantique spécifique à Webpack, vous pouvez placer tous vos CSS directement dans src/index.css
. Il serait toujours importé depuis src/index.js
, mais vous pouvez toujours supprimer cette importation si vous migrez ultérieurement vers un autre outil de construction.
Cette configuration de projet réduit votre CSS et y ajoute automatiquement les préfixes du fournisseur via Autoprefixer afin que vous n'ayez pas à vous en soucier.
Par exemple, ceci :
. App {
display : flex;
flex-direction : row;
align-items : center;
}
devient ceci :
. 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 vous devez désactiver le préfixe automatique pour une raison quelconque, suivez cette section.
En règle générale, nous vous recommandons de ne pas réutiliser les mêmes classes CSS dans différents composants. Par exemple, au lieu d'utiliser une classe CSS .Button
dans les composants <AcceptButton>
et <RejectButton>
, nous vous recommandons de créer un composant <Button>
avec ses propres styles .Button
, que <AcceptButton>
et <RejectButton>
peuvent restituer (mais pas hériter).
Suivre cette règle rend souvent les préprocesseurs CSS moins utiles, car des fonctionnalités telles que les mixins et l'imbrication sont remplacées par la composition des composants. Vous pouvez cependant intégrer un préprocesseur CSS si vous le trouvez utile. Dans cette procédure pas à pas, nous utiliserons Sass, mais vous pouvez également utiliser Less ou une autre alternative.
Tout d'abord, installons l'interface de ligne de commande pour Sass :
npm install --save node-sass-chokidar
Alternativement, vous pouvez utiliser yarn
:
yarn add node-sass-chokidar
Puis dans package.json
, ajoutez les lignes suivantes aux 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",
Remarque : Pour utiliser un autre préprocesseur, remplacez les commandes
build-css
etwatch-css
conformément à la documentation de votre préprocesseur.
Vous pouvez maintenant renommer src/App.css
en src/App.scss
et exécuter npm run watch-css
. L'observateur trouvera chaque fichier Sass dans les sous-répertoires src
et créera un fichier CSS correspondant à côté, en écrasant dans notre cas src/App.css
. Puisque src/App.js
importe toujours src/App.css
, les styles deviennent une partie de votre application. Vous pouvez maintenant modifier src/App.scss
et src/App.css
sera régénéré.
Pour partager des variables entre des fichiers Sass, vous pouvez utiliser les importations Sass. Par exemple, src/App.scss
et d'autres fichiers de style de composant pourraient inclure @import "./shared.scss";
avec des définitions variables.
Pour activer l'importation de fichiers sans utiliser de chemins relatifs, vous pouvez ajouter l'option --include-path
à la commande dans 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",
Cela vous permettra de faire des importations comme
@import ' styles/_colors.scss ' ; // assuming a styles directory under src/
@import ' nprogress/nprogress ' ; // importing a css file from the nprogress node module
À ce stade, vous souhaiterez peut-être supprimer tous les fichiers CSS du contrôle de source et ajouter src/**/*.css
à votre fichier .gitignore
. C'est généralement une bonne pratique de conserver les produits de construction en dehors du contrôle de code source.
Comme dernière étape, vous trouverez peut-être pratique d'exécuter watch-css
automatiquement avec npm start
et d'exécuter build-css
dans le cadre de npm run build
. Vous pouvez utiliser l'opérateur &&
pour exécuter deux scripts séquentiellement. Cependant, il n'existe aucun moyen multiplateforme d'exécuter deux scripts en parallèle, nous allons donc installer un package pour cela :
npm install --save npm-run-all
Alternativement, vous pouvez utiliser yarn
:
yarn add npm-run-all
Ensuite, nous pouvons modifier les scripts start
et build
pour inclure les commandes du préprocesseur 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"
}
L'exécution désormais npm start
et npm run build
crée également des fichiers Sass.
Pourquoi node-sass-chokidar
?
node-sass
a été signalé comme présentant les problèmes suivants :
node-sass --watch
aurait des problèmes de performances dans certaines conditions lorsqu'il est utilisé dans une machine virtuelle ou avec Docker.
Compilation de styles infinis #1939
node-sass
a été signalé comme ayant des problèmes pour détecter de nouveaux fichiers dans un répertoire #1891
node-sass-chokidar
est utilisé ici car il résout ces problèmes.
Avec Webpack, l'utilisation d'actifs statiques tels que des images et des polices fonctionne de la même manière que CSS.
Vous pouvez import
un fichier directement dans un module JavaScript . Cela indique à Webpack d'inclure ce fichier dans le bundle. Contrairement aux importations CSS, l'importation d'un fichier vous donne une valeur de chaîne. Cette valeur est le chemin final que vous pouvez référencer dans votre code, par exemple en tant qu'attribut src
d'une image ou href
d'un lien vers un PDF.
Pour réduire le nombre de requêtes adressées au serveur, l'importation d'images de moins de 10 000 octets renvoie un URI de données au lieu d'un chemin. Cela s'applique aux extensions de fichiers suivantes : bmp, gif, jpg, jpeg et png. Les fichiers SVG sont exclus en raison du #1153.
Voici un exemple :
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 ;
Cela garantit que lorsque le projet est construit, Webpack déplacera correctement les images dans le dossier de construction et nous fournira les chemins corrects.
Cela fonctionne aussi en CSS :
. Logo {
background-image : url (. / logo.png);
}
Webpack trouve toutes les références relatives aux modules en CSS (elles commencent par ./
) et les remplace par les chemins finaux du bundle compilé. Si vous faites une faute de frappe ou supprimez accidentellement un fichier important, vous verrez une erreur de compilation, tout comme lorsque vous importez un module JavaScript inexistant. Les noms de fichiers finaux du bundle compilé sont générés par Webpack à partir des hachages de contenu. Si le contenu du fichier change à l'avenir, Webpack lui donnera un nom différent en production afin que vous n'ayez pas à vous soucier de la mise en cache à long terme des actifs.
Veuillez noter qu'il s'agit également d'une fonctionnalité personnalisée de Webpack.
Ce n'est pas obligatoire pour React mais beaucoup de gens l'apprécient (et React Native utilise un mécanisme similaire pour les images).
Une autre manière de gérer les actifs statiques est décrite dans la section suivante.
public
Remarque : cette fonctionnalité est disponible avec
[email protected]
et versions ultérieures.
Le dossier public
contient le fichier HTML afin que vous puissiez le modifier, par exemple pour définir le titre de la page. La balise <script>
avec le code compilé y sera ajoutée automatiquement pendant le processus de construction.
Vous pouvez également ajouter d'autres ressources au dossier public
.
Notez que nous vous encourageons normalement à import
des ressources dans des fichiers JavaScript. Par exemple, consultez les sections sur l'ajout d'une feuille de style et l'ajout d'images et de polices. Ce mécanisme offre de nombreux avantages :
Cependant, il existe une trappe de secours que vous pouvez utiliser pour ajouter un actif en dehors du système de modules.
Si vous placez un fichier dans le dossier public
, il ne sera pas traité par Webpack. Au lieu de cela, il sera copié dans le dossier de construction sans modification. Pour référencer des ressources dans le dossier public
, vous devez utiliser une variable spéciale appelée PUBLIC_URL
.
Dans index.html
, vous pouvez l'utiliser comme ceci :
< link rel =" shortcut icon " href =" %PUBLIC_URL%/favicon.ico " >
Seuls les fichiers du dossier public
seront accessibles par le préfixe %PUBLIC_URL%
. Si vous devez utiliser un fichier de src
ou node_modules
, vous devrez le copier ici pour spécifier explicitement votre intention d'intégrer ce fichier à la construction.
Lorsque vous exécutez npm run build
, Create React App remplacera %PUBLIC_URL%
par un chemin absolu correct afin que votre projet fonctionne même si vous utilisez le routage côté client ou si vous l'hébergez sur une URL non racine.
Dans le code JavaScript, vous pouvez utiliser process.env.PUBLIC_URL
à des fins similaires :
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' } /> ;
}
Gardez à l’esprit les inconvénients de cette approche :
public
n'est post-traité ou minifié.public
Normalement, nous recommandons d'importer des feuilles de style, des images et des polices depuis JavaScript. Le dossier public
est utile comme solution de contournement pour un certain nombre de cas moins courants :
manifest.webmanifest
.pace.js
en dehors du code fourni.<script>
. Notez que si vous ajoutez un <script>
qui déclare des variables globales, vous devez également lire la section suivante sur leur utilisation.
Lorsque vous incluez un script dans le fichier HTML qui définit des variables globales et essayez d'utiliser l'une de ces variables dans le code, le linter se plaindra car il ne peut pas voir la définition de la variable.
Vous pouvez éviter cela en lisant explicitement la variable globale à partir de l'objet window
, par exemple :
const $ = window . $ ;
Cela montre clairement que vous utilisez une variable globale intentionnellement plutôt qu'à cause d'une faute de frappe.
Alternativement, vous pouvez forcer le linter à ignorer n'importe quelle ligne en ajoutant // eslint-disable-line
après.
Vous n'êtes pas obligé d'utiliser React Bootstrap avec React, mais il s'agit d'une bibliothèque populaire pour intégrer Bootstrap aux applications React. Si vous en avez besoin, vous pouvez l'intégrer à Create React App en suivant ces étapes :
Installez React Bootstrap et Bootstrap à partir de npm. React Bootstrap n'inclut pas Bootstrap CSS, celui-ci doit donc également être installé :
npm install --save react-bootstrap bootstrap@3
Alternativement, vous pouvez utiliser yarn
:
yarn add react-bootstrap bootstrap@3
Importez le CSS Bootstrap et éventuellement le CSS du thème Bootstrap au début de votre fichier 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.
Importez les composants React Bootstrap requis dans le fichier src/App.js
ou vos fichiers de composants personnalisés :
import { Navbar , Jumbotron , Button } from 'react-bootstrap' ;
Vous êtes maintenant prêt à utiliser les composants React Bootstrap importés dans votre hiérarchie de composants définie dans la méthode de rendu. Voici un exemple App.js
refait à l'aide de React Bootstrap.
Parfois, vous devrez peut-être modifier les styles visuels de Bootstrap (ou d'un package équivalent).
Nous suggérons l’approche suivante :
Voici un exemple d'ajout d'un Bootstrap personnalisé qui suit ces étapes.
Flow est un vérificateur de type statique qui vous aide à écrire du code avec moins de bogues. Consultez cette introduction à l'utilisation des types statiques en JavaScript si vous êtes nouveau dans ce concept.
Les versions récentes de Flow fonctionnent immédiatement avec les projets Create React App.
Pour ajouter Flow à un projet Create React App, suivez ces étapes :
npm install --save flow-bin
(ou yarn add flow-bin
)."flow": "flow"
à la section scripts
de votre package.json
.npm run flow init
(ou yarn flow init
) pour créer un fichier .flowconfig
dans le répertoire racine.// @flow
à tous les fichiers que vous souhaitez saisir check (par exemple, à src/App.js
). Vous pouvez maintenant exécuter npm run flow
(ou yarn flow
) pour vérifier les fichiers pour les erreurs de type. Vous pouvez éventuellement utiliser un IDE comme Nuclide pour une meilleure expérience intégrée. À l’avenir, nous prévoyons de l’intégrer encore plus étroitement dans l’application Create React.
Pour en savoir plus sur Flow, consultez sa documentation.
Create React App ne prescrit pas de solution de routage spécifique, mais React Router est la plus populaire.
Pour l'ajouter, exécutez :
npm install --save react-router-dom
Alternativement, vous pouvez utiliser yarn
:
yarn add react-router-dom
Pour l'essayer, supprimez tout le code dans src/App.js
et remplacez-le par l'un des exemples sur son site Web. L'exemple de base est un bon point de départ.
Notez que vous devrez peut-être configurer votre serveur de production pour prendre en charge le routage côté client avant de déployer votre application.
Remarque : cette fonctionnalité est disponible avec
[email protected]
et versions ultérieures.
Votre projet peut consommer des variables déclarées dans votre environnement comme si elles étaient déclarées localement dans vos fichiers JS. Par défaut, NODE_ENV
sera défini pour vous, ainsi que toutes les autres variables d'environnement commençant par REACT_APP_
.
Les variables d'environnement sont intégrées pendant le temps de construction . Étant donné que Create React App produit un bundle HTML/CSS/JS statique, il ne peut pas les lire au moment de l'exécution. Pour les lire au moment de l'exécution, vous devrez charger du HTML en mémoire sur le serveur et remplacer les espaces réservés au moment de l'exécution, comme décrit ici. Vous pouvez également reconstruire l'application sur le serveur à chaque fois que vous les modifiez.
Remarque : Vous devez créer des variables d'environnement personnalisées commençant par
REACT_APP_
. Toutes les autres variables à l'exception deNODE_ENV
seront ignorées pour éviter d'exposer accidentellement une clé privée sur la machine qui pourrait avoir le même nom. La modification des variables d'environnement vous obligera à redémarrer le serveur de développement s'il est en cours d'exécution.
Ces variables d'environnement seront définies pour vous sur process.env
. Par exemple, avoir une variable d'environnement nommée REACT_APP_SECRET_CODE
sera exposée dans votre JS sous le nom process.env.REACT_APP_SECRET_CODE
.
Il existe également une variable d'environnement intégrée spéciale appelée NODE_ENV
. Vous pouvez le lire depuis process.env.NODE_ENV
. Lorsque vous exécutez npm start
, il est toujours égal à 'development'
, lorsque vous exécutez npm test
il est toujours égal à 'test'
, et lorsque vous exécutez npm run build
pour créer un bundle de production, il est toujours égal à 'production'
. Vous ne pouvez pas remplacer NODE_ENV
manuellement. Cela empêche les développeurs de déployer accidentellement une version de développement lente en production.
Ces variables d'environnement peuvent être utiles pour afficher des informations de manière conditionnelle en fonction de l'endroit où le projet est déployé ou pour consommer des données sensibles qui se trouvent en dehors du contrôle de version.
Tout d’abord, vous devez définir des variables d’environnement. Par exemple, disons que vous vouliez consommer un secret défini dans l'environnement à l'intérieur d'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 >
) ;
}
Lors de la construction, process.env.REACT_APP_SECRET_CODE
sera remplacé par la valeur actuelle de la variable d'environnement REACT_APP_SECRET_CODE
. N'oubliez pas que la variable NODE_ENV
sera définie automatiquement pour vous.
Lorsque vous chargez l'application dans le navigateur et inspectez le <input>
, vous verrez sa valeur définie sur abcdef
, et le texte en gras affichera l'environnement fourni lors de l'utilisation npm start
:
< div >
< small > You are running this application in < b > development </ b > mode. </ small >
< form >
< input type =" hidden " value =" abcdef " />
</ form >
</ div >
Le formulaire ci-dessus recherche une variable appelée REACT_APP_SECRET_CODE
à partir de l'environnement. Afin de consommer cette valeur, nous devons la définir dans l'environnement. Cela peut être fait de deux manières : soit dans votre shell, soit dans un fichier .env
. Ces deux méthodes sont décrites dans les sections suivantes.
Avoir accès au NODE_ENV
est également utile pour effectuer des actions de manière conditionnelle :
if ( process . env . NODE_ENV !== 'production' ) {
analytics . disable ( ) ;
}
Lorsque vous compilez l'application avec npm run build
, l'étape de minification supprimera cette condition et le bundle résultant sera plus petit.
Remarque : cette fonctionnalité est disponible avec
[email protected]
et versions ultérieures.
Vous pouvez également accéder aux variables d'environnement commençant par REACT_APP_
dans le public/index.html
. Par exemple:
< title > %REACT_APP_WEBSITE_NAME% </ title >
Notez que les mises en garde de la section ci-dessus s'appliquent :
NODE_ENV
et PUBLIC_URL
), les noms de variables doivent commencer par REACT_APP_
pour fonctionner.La définition des variables d'environnement peut varier selon les systèmes d'exploitation. Il est également important de savoir que cette manière est temporaire pour la durée de vie de la session shell.
set " REACT_APP_SECRET_CODE = abcdef " && npm start
(Remarque : les guillemets autour de l'affectation de variable sont requis pour éviter les espaces de fin.)
( $ env: REACT_APP_SECRET_CODE = " abcdef " ) -and (npm start)
REACT_APP_SECRET_CODE=abcdef npm start
.env
Remarque : cette fonctionnalité est disponible avec
[email protected]
et versions ultérieures.
Pour définir des variables d'environnement permanentes, créez un fichier appelé .env
à la racine de votre projet :
REACT_APP_SECRET_CODE=abcdef
Remarque : Vous devez créer des variables d'environnement personnalisées commençant par
REACT_APP_
. Toutes les autres variables à l'exception deNODE_ENV
seront ignorées pour éviter d'exposer accidentellement une clé privée sur la machine qui pourrait avoir le même nom. La modification des variables d'environnement vous obligera à redémarrer le serveur de développement s'il est en cours d'exécution.
Les fichiers .env
doivent être archivés dans le contrôle de code source (à l'exclusion de .env*.local
).
.env
peuvent être utilisés ?Remarque : cette fonctionnalité est disponible avec
[email protected]
et versions ultérieures .
.env
: Par défaut..env.local
: remplacements locaux. Ce fichier est chargé pour tous les environnements sauf test..env.development
, .env.test
, .env.production
: Paramètres spécifiques à l'environnement..env.development.local
, .env.test.local
, .env.production.local
: remplacements locaux des paramètres spécifiques à l'environnement.Les fichiers de gauche ont plus de priorité que les fichiers de droite :
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
(notez que .env.local
est manquant) Ces variables serviront de défaut si la machine ne les définit pas explicitement.
Veuillez vous référer à la documentation Dotenv pour plus de détails.
Remarque: Si vous définissez des variables d'environnement pour le développement, votre CI et / ou votre plate-forme d'hébergement en aura probablement besoin également de définir. Consultez leur documentation sur la façon de procéder. Par exemple, voir la documentation de Travis CI ou Heroku.
.env
Remarque: Cette fonctionnalité est disponible avec
[email protected]
et plus.
Développez déjà les variables sur votre machine à utiliser dans votre fichier .env
(en utilisant Dotenv-Expand).
Par exemple, pour obtenir la variable d'environnement npm_package_version
:
REACT_APP_VERSION=$npm_package_version
# also works:
# REACT_APP_VERSION=${npm_package_version}
Ou étendre les variables locales au fichier .env
actuel:
DOMAIN=www.example.com
REACT_APP_FOO=$DOMAIN/foo
REACT_APP_BAR=$DOMAIN/bar
De nombreuses bibliothèques populaires utilisent des décorateurs dans leur documentation.
Créer l'application React ne prend pas en charge la syntaxe de décorateur pour le moment car:
Cependant, dans de nombreux cas, vous pouvez réécrire du code basé sur le décorateur sans décorateurs tout aussi bien.
Veuillez vous référer à ces deux threads pour référence:
Créer l'application React ajoutera la prise en charge du décorateur lorsque la spécification passe à une étape stable.
React ne prescrit pas une approche spécifique de la récupération des données, mais les gens utilisent généralement une bibliothèque comme Axios ou l'API fetch()
fournie par le navigateur. Idéalement, Create React App comprend un polyfill pour fetch()
afin que vous puissiez l'utiliser sans vous soucier de la prise en charge du navigateur.
La fonction Global fetch
permet de faire facilement des demandes AJAX. Il prend une URL en entrée et renvoie une Promise
qui se résout en un objet Response
. Vous pouvez trouver plus d'informations sur fetch
ici.
Ce projet comprend également un polyfill prometteur qui fournit une implémentation complète de promesses / A +. Une promesse représente le résultat éventuel d'une opération asynchrone, vous pouvez trouver plus d'informations sur les promesses ici et ici. Axios et fetch()
utilisent les promesses sous le capot. Vous pouvez également utiliser la syntaxe async / await
pour réduire la nidification de rappel.
Vous pouvez en savoir plus sur la création de demandes AJAX à partir de composants React dans l'entrée de la FAQ sur le site Web React.
Ces tutoriels vous aideront à intégrer votre application avec un backend API fonctionnant sur un autre port, en utilisant fetch()
pour y accéder.
Découvrez ce tutoriel. Vous pouvez trouver le référentiel complémentaire GitHub ici.
Découvrez ce tutoriel. Vous pouvez trouver le référentiel complémentaire GitHub ici.
Remarque: Cette fonctionnalité est disponible avec
[email protected]
et plus.
Les gens servent souvent l'application REACT front-end à partir du même hôte et du même port que leur implémentation backend.
Par exemple, une configuration de production peut ressembler à ceci une fois l'application déployée:
/ - 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
Une telle configuration n'est pas requise. Cependant, si vous avez une configuration comme celle-ci, il est pratique d'écrire des demandes comme fetch('/api/todos')
sans se soucier de les rediriger vers un autre hôte ou port pendant le développement.
Pour dire au serveur de développement de proxyer toutes les demandes inconnues à votre serveur API en développement, ajoutez un champ proxy
à votre package.json
, par exemple:
"proxy" : "http://localhost:4000" ,
De cette façon, lorsque vous fetch('/api/todos')
en développement, le serveur de développement reconnaîtra qu'il ne s'agit pas d'un atout statique et procurera votre demande à http://localhost:4000/api/todos
en tant que repli. Le serveur de développement tentera uniquement d'envoyer des demandes sans text/html
dans son en-tête Accept
vers le proxy.
Idéalement, cela évite les problèmes de CORS et les messages d'erreur comme celui-ci en développement:
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.
Gardez à l'esprit que proxy
n'a un effet que dans le développement (avec npm start
), et c'est à vous de vous assurer que les URL comme /api/todos
pointent vers la bonne chose en production. Vous n'avez pas à utiliser le préfixe /api
. Toute demande non reconnue sans en-tête text/html
accepter sera redirigé vers le proxy
spécifié.
L'option proxy
prend en charge les connexions HTTP, HTTPS et WebSocket.
Si l'option proxy
n'est pas suffisamment flexible pour vous, vous pouvez également:
Lorsque vous activez l'option proxy
, vous optez pour un ensemble plus strict de vérifications d'hôte. Ceci est nécessaire car laisser le backend ouvert aux hôtes distants rend votre ordinateur vulnérable aux attaques de référence DNS. Le problème est expliqué dans cet article et ce problème.
Cela ne devrait pas vous affecter lorsque vous vous développez sur localhost
, mais si vous développez à distance comme décrit ici, vous verrez cette erreur dans le navigateur après avoir activé l'option proxy
:
En-tête hôte non valide
Pour y contourner, vous pouvez spécifier votre hôte de développement public dans un fichier appelé .env.development
à la racine de votre projet:
HOST=mypublicdevhost.com
Si vous redémarrez le serveur de développement maintenant et chargez l'application à partir de l'hôte spécifié, cela devrait fonctionner.
Si vous rencontrez toujours des problèmes ou si vous utilisez un environnement plus exotique comme un éditeur de cloud, vous pouvez contourner complètement la vérification de l'hôte en ajoutant une ligne à .env.development.local
. Notez que cela est dangereux et expose votre machine à l'exécution du code distant à partir de sites Web malveillants:
# NOTE: THIS IS DANGEROUS!
# It exposes your machine to attacks from the websites you visit.
DANGEROUSLY_DISABLE_HOST_CHECK=true
Nous ne recommandons pas cette approche.
Remarque: Cette fonctionnalité est disponible avec
[email protected]
et plus.
Si l'option proxy
n'est pas suffisamment flexible pour vous, vous pouvez spécifier un objet dans le formulaire suivant (dans package.json
).
Vous pouvez également spécifier toute valeur de configuration http-proxy-middleware
ou http-proxy
Prise en charge.
{
// ...
"proxy" : {
"/api" : {
"target" : "<url>" ,
"ws" : true
// ...
}
}
// ...
}
Toutes les demandes correspondant à ce chemin seront des procurations, sans exception. Cela inclut les demandes de text/html
, ce que l'option proxy
standard ne se procure pas.
Si vous avez besoin de spécifier plusieurs indicateurs, vous pouvez le faire en spécifiant des entrées supplémentaires. Les correspondances sont des expressions régulières, afin que vous puissiez utiliser un regexp pour correspondre à plusieurs chemins.
{
// ...
"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>"
// ...
}
}
// ...
}
Lors de la configuration d'un proxy WebSocket, il y a quelques considérations supplémentaires à connaître.
Si vous utilisez un moteur WebSocket comme Socket.io, vous devez avoir un serveur Socket.io en cours d'exécution que vous pouvez utiliser comme cible proxy. Socket.io ne fonctionnera pas avec un serveur WebSocket standard. Plus précisément, ne vous attendez pas à ce que socket.io fonctionne avec le test echo WebSocket.org.
Il existe une bonne documentation disponible pour configurer un serveur socket.io.
Standard Websockets fonctionnera avec un serveur WebSocket standard ainsi que le test Websocking.org Echo. Vous pouvez utiliser des bibliothèques comme WS pour le serveur, avec des websockets natifs dans le navigateur.
Quoi qu'il en soit, vous pouvez procurer les demandes WebSocket manuellement dans 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
// ...
}
}
// ...
}
Remarque: Cette fonctionnalité est disponible avec
[email protected]
et plus.
Vous pouvez exiger que le serveur de développement dessert des pages via HTTPS. Un cas particulier où cela pourrait être utile est lors de l'utilisation de la fonction "proxy" aux demandes de proxy à un serveur API lorsque ce serveur API sert lui-même HTTPS.
Pour ce faire, définissez la variable d'environnement HTTPS
sur true
, puis démarrez le serveur de développement comme d'habitude avec npm start
:
set HTTPS = true && npm start
( $ env: HTTPS = $true ) -and (npm start)
(Remarque: le manque d'espace est intentionnel.)
HTTPS=true npm start
Notez que le serveur utilisera un certificat auto-signé, de sorte que votre navigateur Web affichera presque certainement un avertissement sur l'accès à la page.
<meta>
dynamiques sur le serveur Étant donné que la création de l'application React ne prend pas en charge le rendu du serveur, vous vous demandez peut-être comment rendre les balises <meta>
dynamiques et refléter l'URL actuelle. Pour résoudre ce problème, nous vous recommandons d'ajouter des espaces réservés dans le HTML, comme ceci:
<!doctype html >
< html lang =" en " >
< head >
< meta property =" og:title " content =" __OG_TITLE__ " >
< meta property =" og:description " content =" __OG_DESCRIPTION__ " >
Ensuite, sur le serveur, quel que soit le backend que vous utilisez, vous pouvez lire index.html
en mémoire et remplacer __OG_TITLE__
, __OG_DESCRIPTION__
, et tout autre espace réservé par des valeurs en fonction de l'URL actuelle. Assurez-vous simplement de désinfecter et d'échapper aux valeurs interpolées afin qu'ils soient en sécurité à intégrer dans HTML!
Si vous utilisez un serveur de nœuds, vous pouvez même partager la logique de correspondance d'itinéraire entre le client et le serveur. Cependant, la duplication fonctionne également bien dans des cas simples.
Si vous hébergez votre build
avec un fournisseur d'hébergement statique, vous pouvez utiliser React-Snapshot ou React-Snap pour générer des pages HTML pour chaque itinéraire ou lien relatif, dans votre application. Ces pages deviendront alors de manière transparente active, ou «hydratée», lorsque le faisceau JavaScript sera chargé.
Il existe également des opportunités de l'utiliser en dehors de l'hébergement statique, pour éliminer la pression du serveur lors de la génération et de la mise en cache des itinéraires.
Le principal avantage de la pré-rendu est que vous obtenez le contenu principal de chaque page avec la charge utile HTML - sans que votre bundle JavaScript puisse ou non télécharger avec succès. Cela augmente également la probabilité que chaque itinéraire de votre application soit récupérée par les moteurs de recherche.
Vous pouvez en savoir plus sur le pré-rendu zéro configuration (également appelé instantané) ici.
De façon similaire à la section précédente, vous pouvez laisser certains espaces réservés dans le HTML qui injectent des variables globales, par exemple:
< ! doctype html >
< html lang = "en" >
< head >
< script >
window.SERVER_DATA = __SERVER_DATA__;
</ script >
Ensuite, sur le serveur, vous pouvez remplacer __SERVER_DATA__
par un JSON de données réelles juste avant d'envoyer la réponse. Le code client peut alors lire window.SERVER_DATA
pour l'utiliser. Assurez-vous de désinfecter le JSON avant de l'envoyer au client car il rend votre application vulnérable aux attaques XSS.
Remarque: Cette fonctionnalité est disponible avec
[email protected]
et plus.
Lisez le guide de migration pour apprendre à l'activer dans des projets plus anciens!
Créer l'application React utilise la plaisanterie comme coureur de test. Pour nous préparer à cette intégration, nous avons fait une refonte majeure de plaisanterie, donc si vous en avez entendu de mauvaises choses il y a des années, essayez un autre essai.
Jest est un coureur basé sur des nœuds. Cela signifie que les tests s'exécutent toujours dans un environnement de nœud et non dans un véritable navigateur. Cela nous permet de permettre une vitesse d'itération rapide et d'empêcher la négociation.
Bien que Jest fournit des globals de navigateur tels que window
grâce à JSDom, ce ne sont que des approximations du comportement réel du navigateur. La plaisanterie est destinée à être utilisée pour les tests unitaires de votre logique et de vos composants plutôt que les bizarreries DOM.
Nous vous recommandons d'utiliser un outil séparé pour les tests de bout en bout du navigateur si vous en avez besoin. Ils sont au-delà de la portée de Create React App.
Jest recherchera des fichiers de test avec l'une des conventions de dénomination populaires suivantes:
.js
dans les dossiers __tests__
..test.js
suffix..spec.js
. Les fichiers .test.js
/ .spec.js
(ou les dossiers __tests__
) peuvent être situés à n'importe quelle profondeur dans le dossier src
de niveau supérieur.
Nous vous recommandons de mettre les fichiers de test (ou les dossiers __tests__
) à côté du code qu'ils testent afin que les importations relatives semblent plus courtes. Par exemple, si App.test.js
et App.js
sont dans le même dossier, le test doit simplement import App from './App'
au lieu d'un long chemin relatif. La colocation aide également à trouver des tests plus rapidement dans des projets plus importants.
Lorsque vous exécutez npm test
, la plaisanterie sera lancée en mode de montre. Chaque fois que vous enregistrez un fichier, il réévaluera les tests, tout comme npm start
Recompile le code.
L'observateur comprend une interface de ligne de commande interactive avec la possibilité d'exécuter tous les tests ou de se concentrer sur un modèle de recherche. Il est conçu de cette façon pour que vous puissiez le garder ouvert et profiter de réécritures rapides. Vous pouvez apprendre les commandes de la note «Utilisation de la montre» que l'observateur imprime après chaque course:
Par défaut, lorsque vous exécutez npm test
, jest ne fera que les tests liés aux fichiers modifiés depuis le dernier engagement. Il s'agit d'une optimisation conçue pour faire fonctionner vos tests rapidement, quel que soit le nombre de tests dont vous passez. Cependant, cela suppose que vous ne commettez pas souvent le code qui ne réussit pas les tests.
Jest mentionnera toujours explicitement qu'il n'a effectué que des tests liés aux fichiers modifiés depuis le dernier engagement. Vous pouvez également appuyer sur a
dans le mode de montre pour forcer la plaisanterie à exécuter tous les tests.
Jest exécutera toujours tous les tests sur un serveur d'intégration continue ou si le projet n'est pas dans un référentiel GIT ou Mercurial.
Pour créer des tests, ajoutez it()
(ou test()
) des blocs avec le nom du test et son code. Vous pouvez éventuellement les envelopper dans des blocs describe()
pour le regroupement logique, mais cela n'est ni requis ni recommandé.
Jest fournit une fonction globale expect()
intégrée pour faire des affirmations. Un test de base pourrait ressembler à ceci:
import sum from './sum' ;
it ( 'sums numbers' , ( ) => {
expect ( sum ( 1 , 2 ) ) . toEqual ( 3 ) ;
expect ( sum ( 2 , 2 ) ) . toEqual ( 4 ) ;
} ) ;
Tous les correspondances expect()
prises en charge par Jest sont largement documentées ici.
Vous pouvez également utiliser jest.fn()
et expect(fn).toBeCalled()
pour créer des fonctions «espions» ou simulées.
Il existe un large éventail de techniques de test des composants. Ils vont d'un «test de fumée», vérifiant qu'un composant rende sans lancer, au rendu peu profond et à la test d'une partie de la sortie, au rendu complet et au test du cycle de vie des composants et aux modifications d'état.
Différents projets choisissent différents compromis de tests en fonction de la fréquence à laquelle les composants changent et de la quantité de logique qu'elles contiennent. Si vous n'avez pas encore décidé d'une stratégie de test, nous vous recommandons de commencer par la création de tests de fumée simples pour vos composants:
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 ) ;
} ) ;
Ce test monte un composant et s'assure qu'il n'a pas jeté pendant le rendu. Des tests comme celui-ci offrent beaucoup de valeur avec très peu d'efforts, ils sont donc excellents comme point de départ, et c'est le test que vous trouverez dans src/App.test.js
Lorsque vous rencontrez des bogues provoqués par la modification des composants, vous aurez un aperçu plus profond de la peine de tester dans votre application. Cela pourrait être un bon moment pour introduire des tests plus spécifiques affirmant une sortie ou un comportement attendu spécifique.
Si vous souhaitez tester les composants isolément des composants de l'enfant qu'ils rendent, nous vous recommandons d'utiliser une API de rendu shallow()
de l'enzyme. Pour l'installer, exécutez:
npm install --save enzyme enzyme-adapter-react-16 react-test-renderer
Vous pouvez également utiliser yarn
:
yarn add enzyme enzyme-adapter-react-16 react-test-renderer
En tant qu'enzyme 3, vous devrez installer Enzyme avec un adaptateur correspondant à la version de React que vous utilisez. (Les exemples ci-dessus utilisent l'adaptateur pour React 16.)
L'adaptateur devra également être configuré dans votre fichier de configuration global:
src/setupTests.js
import { configure } from 'enzyme' ;
import Adapter from 'enzyme-adapter-react-16' ;
configure ( { adapter : new Adapter ( ) } ) ;
Remarque: Gardez à l'esprit que si vous décidez "d'éjecter" avant de créer
src/setupTests.js
, le fichierpackage.json
résultant ne contiendra aucune référence. Lisez ici pour apprendre à l'ajouter après l'éjection.
Vous pouvez maintenant écrire un test de fumée avec:
import React from 'react' ;
import { shallow } from 'enzyme' ;
import App from './App' ;
it ( 'renders without crashing' , ( ) => {
shallow ( < App /> ) ;
} ) ;
Contrairement au test de fumée précédent à l'aide de ReactDOM.render()
, ce test ne fait que <App>
et ne va pas plus loin. Par exemple, même si <App>
lui-même rend un <Button>
qui lance, ce test passera. Le rendu peu profond est idéal pour les tests unitaires isolés, mais vous pouvez toujours créer des tests de rendu complets pour vous assurer que les composants s'intégrent correctement. Enzyme prend en charge le rendu complet avec mount()
, et vous pouvez également l'utiliser pour tester les modifications d'état et le cycle de vie des composants.
Vous pouvez lire la documentation enzymatique pour plus de techniques de test. La documentation enzymatique utilise Chai et Sinon pour les affirmations, mais vous n'avez pas à les utiliser car Jest fournit expect()
et jest.fn()
pour les espions.
Voici un exemple de la documentation Enzyme qui affirme une sortie spécifique, réécrite pour utiliser des matchs en plaisantage:
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 ) ;
} ) ;
Tous les matchs de plaisanterie sont largement documentés ici.
Néanmoins, vous pouvez utiliser une bibliothèque d'assertions tierces comme Chai si vous le souhaitez, comme décrit ci-dessous.
De plus, vous pourriez trouver une enzyme en plaisantage pour simplifier vos tests avec des matchs lisibles. Ce qui précède contains
du code peut être écrit plus simplement avec une enzyme en plaisantage.
expect ( wrapper ) . toContainReact ( welcome )
Pour activer cela, installez jest-enzyme
:
npm install --save jest-enzyme
Vous pouvez également utiliser yarn
:
yarn add jest-enzyme
Importez-le dans src/setupTests.js
pour rendre ses matchs disponibles dans chaque test:
import 'jest-enzyme' ;
Nous vous recommandons d'utiliser expect()
pour les assertions et jest.fn()
pour les espions. Si vous rencontrez des problèmes avec eux, veuillez les déposer contre la plaisanterie et nous les réparerons. Nous avons l'intention de continuer à les améliorer pour React, en soutenant, par exemple, des éléments de réaction assez imprimés en tant que JSX.
Cependant, si vous êtes habitué à d'autres bibliothèques, tels que Chai et Sinon, ou si vous avez du code existant qui les utilise que vous souhaitez porter, vous pouvez les importer normalement comme ceci:
import sinon from 'sinon' ;
import { expect } from 'chai' ;
puis utilisez-les dans vos tests comme vous le faites normalement.
Remarque: Cette fonctionnalité est disponible avec
[email protected]
et plus.
Si votre application utilise une API de navigateur que vous devez vous moquer de vos tests ou si vous avez juste besoin d'une configuration globale avant d'exécuter vos tests, ajoutez un src/setupTests.js
à votre projet. Il sera automatiquement exécuté avant d'exécuter vos tests.
Par exemple:
src/setupTests.js
const localStorageMock = {
getItem : jest . fn ( ) ,
setItem : jest . fn ( ) ,
clear : jest . fn ( )
} ;
global . localStorage = localStorageMock
Remarque: Gardez à l'esprit que si vous décidez "d'éjecter" avant de créer
src/setupTests.js
, le fichierpackage.json
résultant ne contiendra aucune référence, vous devez donc créer manuellement la propriétésetupTestFrameworkScriptFile
dans la configuration de la plaisanterie, quelque chose comme les suivants:
"jest" : { // ... "setupTestFrameworkScriptFile" : "<rootDir>/src/setupTests.js" }
Vous pouvez it()
par xit()
pour exclure temporairement un test de l'exécution.
De même, fit()
vous permet de vous concentrer sur un test spécifique sans exécuter d'autres tests.
Jest a un journaliste de couverture intégré qui fonctionne bien avec ES6 et ne nécessite aucune configuration.
Exécutez npm test -- --coverage
(Remarque Extra --
au milieu) pour inclure un rapport de couverture comme celui-ci:
Notez que les tests fonctionnent beaucoup plus lentement avec la couverture, il est donc recommandé de l'exécuter séparément de votre flux de travail normal.
La configuration de la couverture de plaisanterie par défaut peut être remplacée en ajoutant l'une des clés prises en charge suivantes à une configuration de plaisanterie dans votre package.json.
Remplacements pris en charge:
collectCoverageFrom
coverageReporters
coverageThreshold
snapshotSerializers
Exemple package.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 " ]
}
}
Par défaut, npm test
exécute l'observateur avec une CLI interactive. Cependant, vous pouvez le forcer à exécuter des tests une fois et à terminer le processus en définissant une variable d'environnement appelée CI
.
Lors de la création d'une génération de votre application avec npm run build
Linter Les avertissements ne sont pas vérifiés par défaut. Comme npm test
, vous pouvez forcer la construction à effectuer une vérification d'avertissement Linter en définissant l' CI
de la variable d'environnement. Si des avertissements sont rencontrés, la construction échoue.
Les serveurs CI populaires définissent déjà la variable d'environnement CI
par défaut, mais vous pouvez également le faire vous-même:
.travis.yml
à votre référentiel GIT. language: node_js
node_js:
- 6
cache:
directories:
- node_modules
script:
- npm run build
- npm test
Suivez cet article pour configurer Circleci avec un projet Create React App.
set CI = true && npm test
set CI = true && npm run build
(Remarque: le manque d'espace est intentionnel.)
( $ env: CI = $true ) -and (npm test)
( $ env: CI = $true ) -and (npm run build)
CI=true npm test
CI=true npm run build
La commande de test obligera la plaisanterie à exécuter des tests une fois au lieu de lancer l'observateur.
Si vous vous retrouvez souvent en développement, veuillez déposer un problème pour nous parler de votre cas d'utilisation, car nous voulons faire de Watcher la meilleure expérience et nous sommes ouverts à la modification de son fonctionnement pour accueillir plus de workflows.
La commande de construction vérifiera les avertissements de Linter et échouera en cas de trouvé.
Par défaut, le package.json
du projet généré ressemble à ceci:
"scripts" : {
"start" : "react-scripts start" ,
"build" : "react-scripts build" ,
"test" : "react-scripts test --env=jsdom"
Si vous savez qu'aucun de vos tests ne dépend de JSDom, vous pouvez supprimer en toute sécurité --env=jsdom
, et vos tests fonctionneront plus rapidement:
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
- "test": "react-scripts test --env=jsdom"
+ "test": "react-scripts test"
Pour vous aider à décider, voici une liste d'API qui nécessite JSDom :
window
et document
ReactDOM.render()
TestUtils.renderIntoDocument()
(un raccourci pour ce qui précède)mount()
dans enzymeEn revanche, JSDom n'est pas nécessaire pour les API suivantes:
TestUtils.createRenderer()
(rendu peu profond)shallow()
en enzymeEnfin, JSDom n'est pas non plus nécessaire pour les tests d'instantané.
Le test d'instantané est une fonctionnalité de plaisanterie qui génère automatiquement des instantanés de texte de vos composants et les enregistre sur le disque, donc si la sortie de l'interface utilisateur change, vous êtes informé sans écrire manuellement aucune affirmation sur la sortie du composant. En savoir plus sur les tests d'instantané.
Si vous utilisez Visual Studio Code, il existe une extension de plaisanterie qui fonctionne avec Create React App Out of the Box. Cela fournit de nombreuses fonctionnalités de type IDE lors de l'utilisation d'un éditeur de texte: affichant l'état d'un test avec des messages d'échec potentiels en ligne, en démarrant et en arrêtant automatiquement l'observateur, et en offrant des mises à jour d'instantanés en un clic.
Il existe différentes façons de configurer un débogueur pour vos tests de plaisanterie. Nous couvrons le débogage dans le code chrome et visual Studio.
Remarque: Les tests de débogage nécessitent le nœud 8 ou plus.
Ajoutez ce qui suit à la section scripts
dans package.json
de votre projet.json
"scripts" : {
"test:debug" : " react-scripts --inspect-brk test --runInBand --env=jsdom "
}
Placer debugger;
Instructions dans n'importe quel test et exécution:
$ npm run test:debug
Cela commencera à exécuter vos tests de plaisanterie, mais une pause avant de s'exécuter pour permettre à un débogueur de se connecter au processus.
Ouvrez ce qui suit dans Chrome
about:inspect
Après avoir ouvert ce lien, les outils de développeur Chrome seront affichés. Sélectionnez inspect
sur votre processus et un point d'arrêt sera défini sur la première ligne du script React (ceci est fait simplement pour vous donner le temps d'ouvrir les outils du développeur et d'empêcher Jest de s'exécuter avant d'avoir le temps de le faire). Cliquez sur le bouton qui ressemble à un bouton "Play" en haut à droite de l'écran pour continuer l'exécution. Lorsque jest exécute le test qui contient l'instruction Debugger, l'exécution s'arrêtera et vous pouvez examiner la portée et la pile d'appels actuelles.
Remarque: L'option - Runinband CLI s'assure que la plaisanterie exécute le test dans le même processus plutôt que les processus de frai pour les tests individuels. Normalement, la plaisanterie de plaisanterie parallélise des processus, mais il est difficile de déboguer de nombreux processus en même temps.
Le débogage des tests de plaisanterie est pris en charge hors de la boîte pour le code Visual Studio.
Utilisez le fichier de configuration launch.json
suivant:
{
"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"
}
]
}
Habituellement, dans une application, vous avez beaucoup de composants d'interface utilisateur, et chacun a de nombreux états différents. Pour un exemple, un composant de bouton simple pourrait avoir des états suivants:
Habituellement, il est difficile de voir ces états sans exécuter un exemple d'application ni quelques exemples.
Créer l'application React n'inclut pas d'outils pour cela par défaut, mais vous pouvez facilement ajouter un livre de contes pour react (source) ou React StyleGuidist (source) à votre projet. Ce sont des outils tiers qui vous permettent de développer des composants et de voir tous leurs états isolés de votre application .
Vous pouvez également déployer votre livre de contes ou guide de style en tant qu'application statique. De cette façon, tout le monde dans votre équipe peut afficher et examiner différents états de composants d'interface utilisateur sans démarrer un serveur backend ou créer un compte dans votre application.
Le livre de contes est un environnement de développement pour les composants de l'interface utilisateur React. Il vous permet de parcourir une bibliothèque de composants, de visualiser les différents états de chaque composant et de développer et de tester des composants de manière interactive.
Tout d'abord, installez le package NPM suivant à l'échelle mondiale:
npm install -g @storybook/cli
Ensuite, exécutez la commande suivante dans le répertoire de votre application:
getstorybook
Après cela, suivez les instructions à l'écran.
En savoir plus sur React Storybook:
StyleGuidist combine un guide de style, où tous vos composants sont présentés sur une seule page avec leur documentation d'accessoires et leurs exemples d'utilisation, avec un environnement pour développer des composants isolément, similaires au livre de contes. Dans StyleGuidiste, vous écrivez des exemples dans Markdown, où chaque extrait de code est rendu comme un terrain de jeu modifiable en direct.
Tout d'abord, installer StyleGuidist:
npm install --save react-styleguidist
Vous pouvez également utiliser yarn
:
yarn add react-styleguidist
Ensuite, ajoutez ces scripts à votre package.json
:
"scripts": {
+ "styleguide": "styleguidist server",
+ "styleguide:build": "styleguidist build",
"start": "react-scripts start",
Ensuite, exécutez la commande suivante dans le répertoire de votre application:
npm run styleguide
Après cela, suivez les instructions à l'écran.
En savoir plus sur React StyleGuidist:
Create React App ne fournit aucune fonctionnalité intégrée pour publier un composant à NPM. Si vous êtes prêt à extraire un composant de votre projet afin que d'autres personnes puissent l'utiliser, nous vous recommandons de le déplacer vers un répertoire séparé en dehors de votre projet, puis d'utiliser un outil comme NWB pour le préparer à la publication.
Par défaut, la version de production est une application Web progressive entièrement hors ligne et hors ligne.
Les applications Web progressives sont plus rapides et plus fiables que les pages Web traditionnelles et offrent une expérience mobile attrayante:
Le sw-precache-webpack-plugin
est intégré à la configuration de la production, et il s'occupera de générer un fichier de travailleur de service qui préconera automatiquement tous vos actifs locaux et les tiendra à jour lorsque vous déployez des mises à jour. Le travailleur des services utilisera une stratégie d'abord en cache pour gérer toutes les demandes d'actifs locaux, y compris le HTML initial, en veillant à ce que votre application Web soit rapide, même sur un réseau lent ou peu fiable.
Si vous préférez ne pas activer les travailleurs du service avant votre déploiement de production initial, supprimez l'appel à registerServiceWorker()
de src/index.js
.
Si vous aviez déjà activé les travailleurs de service dans votre déploiement de production et que vous avez décidé que vous souhaitez les désactiver pour tous vos utilisateurs existants, vous pouvez d'abord échanger l'appel à registerServiceWorker()
dans src/index.js
:
import { unregister } from './registerServiceWorker' ;
puis appelez à la place unregister()
. Une fois que l'utilisateur a rendu visite à une page qui a unregister()
, le travailleur des services sera désinstallé. Notez que selon la façon dont /service-worker.js
est servi, il peut prendre jusqu'à 24 heures pour que le cache soit invalidé.
Les travailleurs du service ont besoin de HTTPS, bien que pour faciliter les tests locaux, cette politique ne s'applique pas à localhost
. Si votre serveur Web de production ne prend pas en charge HTTPS, l'enregistrement des travailleurs de service échouera, mais le reste de votre application Web restera fonctionnel.
Les travailleurs de service ne sont pas actuellement pris en charge dans tous les navigateurs Web. L'inscription des travailleurs de service ne sera pas tentée sur les navigateurs qui manquent de soutien.
Le travailleur des services n'est activé que dans l'environnement de production, par exemple la sortie de npm run build
. Il est recommandé de ne pas activer un employé de service d'abord hors ligne dans un environnement de développement, car il peut entraîner une frustration lorsque des actifs précédemment mis en cache sont utilisés et n'incluez pas les dernières modifications que vous avez apportées localement.
Si vous devez tester localement votre travailleur de service hors ligne, créez l'application (à l'aide de npm run build
) et exécutez un serveur HTTP simple à partir de votre répertoire de build. Après avoir exécuté le script de build, create-react-app
donnera des instructions pour un moyen de tester votre construction de production localement et les instructions de déploiement ont des instructions pour utiliser d'autres méthodes. Assurez-vous de toujours utiliser une fenêtre incognito pour éviter les complications avec votre cache de navigateur.
Si possible, configurez votre environnement de production pour servir le service-worker.js
généré.js avec HTTP Caching Disabled. Si cela n'est pas possible - les pages de GitHub, par exemple, ne vous permettent pas de modifier la durée de vie du cache HTTP de 10 minutes par défaut - alors sachez que si vous visitez votre site de production, puis revisitez à nouveau avant que service-worker.js
ne soit expiré à partir de votre HTTP Cache, vous continuerez à obtenir les actifs précédemment mis en cache auprès du travailleur des services. Si vous avez un besoin immédiat de visualiser votre déploiement de production mis à jour, l'exécution d'un refroidissement de changement de vitesse désactivera temporairement le travailleur des services et récupérera tous les actifs du réseau.
Les utilisateurs ne sont pas toujours familiers avec les applications Web hors ligne. Il peut être utile de faire savoir à l'utilisateur quand le travailleur du service a terminé de remplir vos caches (montrant un message "Cette application Web fonctionne hors ligne! La prochaine fois qu'ils chargent la page (affichant un "nouveau contenu est disponible; veuillez actualiser." Message). Le montage de ces messages est actuellement laissé comme un exercice au développeur, mais comme point de départ, vous pouvez utiliser la logique incluse dans src/registerServiceWorker.js
, qui montre quels événements de cycle de vie des travailleurs de service à écouter pour détecter chaque scénario, et qui par défaut, enregistre simplement les messages appropriés à la console JavaScript.
Par défaut, le fichier de travailleur de service généré n'interceptera ni ne metra en cache un trafic d'origine croisée, comme les demandes, des images ou des intégres HTTP chargées à partir d'un domaine différent. Si vous souhaitez utiliser une stratégie de mise en cache d'exécution pour ces demandes, vous pouvez eject
puis configurer l'option runtimeCaching
dans la section SWPrecacheWebpackPlugin
de webpack.config.prod.js
.
La configuration par défaut comprend un manifeste d'application Web situé sur public/manifest.json
, que vous pouvez personnaliser avec des détails spécifiques à votre application Web.
Lorsqu'un utilisateur ajoute une application Web à son écran d'accueil à l'aide de Chrome ou Firefox sur Android, les métadonnées de manifest.json
déterminent les icônes, les noms et les couleurs de marque à utiliser lorsque l'application Web est affichée. Le guide manifeste de l'application Web fournit plus de contexte sur ce que chaque champ signifie et sur la façon dont vos personnalisations affecteront l'expérience de vos utilisateurs.
L'explorateur de cartes source analyse les faisceaux JavaScript à l'aide des cartes source. Cela vous aide à comprendre d'où vient le ballonnement de code.
Pour ajouter l'Explorateur de carte source à un projet Create React App, suivez ces étapes:
npm install --save source-map-explorer
Vous pouvez également utiliser yarn
:
yarn add source-map-explorer
Ensuite, dans package.json
, ajoutez la ligne suivante aux scripts
:
"scripts": {
+ "analyze": "source-map-explorer build/static/js/main.*",
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test --env=jsdom",
Ensuite, pour analyser le bundle, exécutez la version de production, exécutez le script d'analyse.
npm run build
npm run analyze
npm run build
crée un répertoire build
avec une construction de production de votre application. Configurez votre serveur HTTP préféré afin qu'un visiteur sur votre site soit servi index.html
et que les demandes de chemins statiques comme /static/js/main.<hash>.js
sont servis avec le contenu du /static/js/main.<hash>.js
Fichier /static/js/main.<hash>.js
.
Pour les environnements utilisant le nœud, le moyen le plus simple de gérer cela serait d'installer le service et de le laisser gérer le reste:
npm install -g serve
serve -s build
La dernière commande illustrée ci-dessus servira votre site statique sur le port 5000 . Comme beaucoup de paramètres internes de Service, le port peut être ajusté à l'aide des drapeaux -p
ou --port
.
Exécutez cette commande pour obtenir une liste complète des options disponibles:
serve -h
Vous n'avez pas nécessairement besoin d'un serveur statique afin d'exécuter un projet Create React App dans la production. Il fonctionne tout aussi bien intégré dans une dynamique existante.
Voici un exemple programmatique utilisant Node et Express:
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 ) ;
Le choix de votre logiciel de serveur n'est pas non plus important non plus. Étant donné que la création de l'application React est entièrement autochtone, il n'est pas nécessaire d'utiliser explicitement le nœud.
Le dossier build
avec des actifs statiques est la seule sortie produite par Create React App.
Cependant, cela ne suffit pas si vous utilisez le routage côté client. Read the next section if you want to support URLs like /todos/42
in your single-page app.
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>
.
More information here.
Par exemple:
< 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 | Développement | Production | Usage |
---|---|---|---|
NAVIGATEUR | ✅ | 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. | |
HÔTE | ✅ | By default, the development web server binds to localhost . You may use this variable to specify a different host. | |
PORT | ✅ | 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.
Par exemple:
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!