Este projeto foi inicializado com Create React App.
Abaixo você encontrará algumas informações sobre como realizar tarefas comuns.
Você pode encontrar a versão mais recente deste guia aqui.
<title>
public
public
.env
<meta>
dinâmicas no servidornpm start
não detecta alteraçõesnpm test
trava no macOS Sierranpm run build
sai muito cedonpm run build
falha no Herokunpm run build
falha ao minificarCreate React App é dividido em dois pacotes:
create-react-app
é um utilitário de linha de comando global que você usa para criar novos projetos.react-scripts
é uma dependência de desenvolvimento nos projetos gerados (incluindo este). Você quase nunca precisa atualizar o próprio create-react-app
: ele delega toda a configuração para react-scripts
.
Quando você executa create-react-app
, ele sempre cria o projeto com a versão mais recente dos react-scripts
para que você obtenha automaticamente todos os novos recursos e melhorias nos aplicativos recém-criados.
Para atualizar um projeto existente para uma nova versão de react-scripts
, abra o changelog, encontre a versão em que você está atualmente (verifique package.json
nesta pasta se não tiver certeza) e aplique as instruções de migração para o mais recente versões.
Na maioria dos casos, alterar a versão react-scripts
em package.json
e executar npm install
nesta pasta deve ser suficiente, mas é bom consultar o changelog para possíveis alterações significativas.
Nós nos comprometemos a manter o mínimo de alterações significativas para que você possa atualizar react-scripts
sem problemas.
Estamos sempre abertos ao seu feedback.
Após a criação, seu projeto deverá ficar assim:
my-app/
README.md
node_modules/
package.json
public/
index.html
favicon.ico
src/
App.css
App.js
App.test.js
index.css
index.js
logo.svg
Para que o projeto seja compilado, esses arquivos devem existir com nomes de arquivo exatos :
public/index.html
é o modelo da página;src/index.js
é o ponto de entrada do JavaScript.Você pode excluir ou renomear os outros arquivos.
Você pode criar subdiretórios dentro de src
. Para reconstruções mais rápidas, apenas os arquivos dentro src
são processados pelo Webpack.
Você precisa colocar quaisquer arquivos JS e CSS dentro de src
, caso contrário, o Webpack não os verá.
Somente arquivos dentro public
podem ser usados em public/index.html
.
Leia as instruções abaixo para usar recursos de JavaScript e HTML.
No entanto, você pode criar mais diretórios de nível superior.
Eles não serão incluídos na compilação de produção, portanto você poderá usá-los para coisas como documentação.
No diretório do projeto, você pode executar:
npm start
Executa o aplicativo no modo de desenvolvimento.
Abra http://localhost:3000 para visualizá-lo no navegador.
A página será recarregada se você fizer edições.
Você também verá erros de lint no console.
npm test
Inicia o executor de teste no modo de observação interativo.
Consulte a seção sobre execução de testes para obter mais informações.
npm run build
Cria o aplicativo para produção na pasta build
.
Ele agrupa corretamente o React no modo de produção e otimiza a construção para obter o melhor desempenho.
A compilação é reduzida e os nomes dos arquivos incluem os hashes.
Seu aplicativo está pronto para ser implantado!
Consulte a seção sobre implantação para obter mais informações.
npm run eject
Nota: esta é uma operação unilateral. Depois de eject
, você não pode voltar!
Se não estiver satisfeito com a ferramenta de compilação e as opções de configuração, você poderá eject
a qualquer momento. Este comando removerá a dependência de compilação única do seu projeto.
Em vez disso, ele copiará todos os arquivos de configuração e as dependências transitivas (Webpack, Babel, ESLint, etc) diretamente no seu projeto para que você tenha controle total sobre eles. Todos os comandos, exceto eject
, ainda funcionarão, mas apontarão para os scripts copiados para que você possa ajustá-los. Neste ponto você está sozinho.
Você nunca precisa usar eject
. O conjunto de recursos selecionados é adequado para implantações pequenas e médias e você não deve se sentir obrigado a usar esse recurso. No entanto, entendemos que esta ferramenta não seria útil se você não pudesse personalizá-la quando estiver pronto para isso.
Por padrão, o projeto gerado usa a versão mais recente do React.
Você pode consultar a documentação do React para obter mais informações sobre os navegadores suportados.
Este projeto oferece suporte a um superconjunto do padrão JavaScript mais recente.
Além dos recursos de sintaxe ES6, ele também suporta:
Saiba mais sobre as diferentes etapas da proposta.
Embora recomendemos o uso de propostas experimentais com certa cautela, o Facebook usa muito esses recursos no código do produto, por isso pretendemos fornecer codemods se alguma dessas propostas mudar no futuro.
Observe que o projeto inclui apenas alguns polyfills ES6 :
Object.assign()
através de object-assign
.Promise
através de promise
.fetch()
através de whatwg-fetch
. Se você usar qualquer outro recurso ES6+ que precise de suporte de tempo de execução (como Array.from()
ou Symbol
), certifique-se de incluir os polyfills apropriados manualmente ou de que os navegadores que você está direcionando já os suportam.
Observe também que o uso de alguns recursos de sintaxe mais recentes, como for...of
ou [...nonArrayValue]
faz com que o Babel emita código que depende dos recursos de tempo de execução do ES6 e pode não funcionar sem um polyfill. Em caso de dúvida, use o Babel REPL para ver como qualquer sintaxe específica é compilada.
Para configurar o realce de sintaxe em seu editor de texto favorito, acesse a página de documentação relevante do Babel e siga as instruções. Alguns dos editores mais populares são abordados.
Nota: este recurso está disponível com
[email protected]
e superior.
Também funciona apenas com npm 3 ou superior.
Alguns editores, incluindo Sublime Text, Atom e Visual Studio Code, fornecem plug-ins para ESLint.
Eles não são necessários para fiapos. Você deverá ver a saída do linter diretamente no seu terminal, bem como no console do navegador. No entanto, se você preferir que os resultados do lint apareçam diretamente no seu editor, existem algumas etapas extras que você pode executar.
Você precisaria primeiro instalar um plugin ESLint para o seu editor. Em seguida, adicione um arquivo chamado .eslintrc
à raiz do projeto:
{
"extends" : "react-app"
}
Agora seu editor deve relatar os avisos de linting.
Observe que mesmo se você editar ainda mais seu arquivo .eslintrc
, essas alterações afetarão apenas a integração do editor . Eles não afetarão a saída do terminal e do lint no navegador. Isso ocorre porque o Create React App fornece intencionalmente um conjunto mínimo de regras que encontram erros comuns.
Se você deseja impor um estilo de codificação ao seu projeto, considere usar regras de estilo Prettier em vez de ESLint.
Atualmente, esse recurso é compatível apenas com Visual Studio Code e WebStorm.
Visual Studio Code e WebStorm oferecem suporte à depuração pronta para uso com Create React App. Isso permite que você, como desenvolvedor, escreva e depure seu código React sem sair do editor e, o mais importante, permite que você tenha um fluxo de trabalho de desenvolvimento contínuo, onde a troca de contexto é mínima, já que você não precisa alternar entre ferramentas.
Você precisaria ter a versão mais recente do VS Code e do VS Code Chrome Debugger Extension instalada.
Em seguida, adicione o bloco abaixo ao seu arquivo launch.json
e coloque-o dentro da pasta .vscode
no diretório raiz do seu aplicativo.
{
"version" : " 0.2.0 " ,
"configurations" : [{
"name" : " Chrome " ,
"type" : " chrome " ,
"request" : " launch " ,
"url" : " http://localhost:3000 " ,
"webRoot" : " ${workspaceRoot}/src " ,
"sourceMapPathOverrides" : {
"webpack:///src/*" : " ${webRoot}/* "
}
}]
}
Observação: a URL pode ser diferente se você tiver feito ajustes por meio das variáveis de ambiente HOST ou PORT.
Inicie seu aplicativo executando npm start
e comece a depurar no VS Code pressionando F5
ou clicando no ícone de depuração verde. Agora você pode escrever código, definir pontos de interrupção, fazer alterações no código e depurar seu código recém-modificado — tudo em seu editor.
Está tendo problemas com depuração de código VS? Consulte o guia de solução de problemas.
Você precisaria ter a extensão WebStorm e JetBrains IDE Support Chrome instalada.
No menu Run
do WebStorm, selecione Edit Configurations...
. Em seguida, clique em +
e selecione JavaScript Debug
. Cole http://localhost:3000
no campo URL e salve a configuração.
Observação: a URL pode ser diferente se você tiver feito ajustes por meio das variáveis de ambiente HOST ou PORT.
Inicie seu aplicativo executando npm start
e pressione ^D
no macOS ou F9
no Windows e Linux ou clique no ícone de depuração verde para iniciar a depuração no WebStorm.
Da mesma forma que você pode depurar seu aplicativo no IntelliJ IDEA Ultimate, PhpStorm, PyCharm Pro e RubyMine.
Prettier é um formatador de código opinativo com suporte para JavaScript, CSS e JSON. Com Prettier você pode formatar o código que escreve automaticamente para garantir um estilo de código dentro do seu projeto. Consulte a página GitHub do Prettier para obter mais informações e consulte esta página para vê-la em ação.
Para formatar nosso código sempre que fizermos um commit no git, precisamos instalar as seguintes dependências:
npm install --save husky lint-staged prettier
Alternativamente, você pode usar yarn
:
yarn add husky lint-staged prettier
husky
facilita o uso de githooks como se fossem scripts npm.lint-staged
nos permite executar scripts em arquivos preparados no git. Veja esta postagem do blog sobre lint-staged para saber mais sobre ele.prettier
é o formatador JavaScript que executaremos antes dos commits. Agora podemos garantir que cada arquivo esteja formatado corretamente adicionando algumas linhas ao package.json
na raiz do projeto.
Adicione a seguinte linha à seção scripts
:
"scripts": {
+ "precommit": "lint-staged",
"start": "react-scripts start",
"build": "react-scripts build",
Em seguida, adicionamos um campo 'lint-staged' ao package.json
, por exemplo:
"dependencies": {
// ...
},
+ "lint-staged": {
+ "src/**/*.{js,jsx,json,css}": [
+ "prettier --single-quote --write",
+ "git add"
+ ]
+ },
"scripts": {
Agora, sempre que você fizer um commit, o Prettier formatará os arquivos alterados automaticamente. Você também pode executar ./node_modules/.bin/prettier --single-quote --write "src/**/*.{js,jsx,json,css}"
para formatar todo o seu projeto pela primeira vez.
Em seguida, você pode querer integrar o Prettier ao seu editor favorito. Leia a seção sobre Integração do Editor na página Prettier GitHub.
<title>
Você pode encontrar o arquivo HTML de origem na pasta public
do projeto gerado. Você pode editar a tag <title>
para alterar o título de “React App” para qualquer outro.
Observe que normalmente você não editaria arquivos na pasta public
com muita frequência. Por exemplo, adicionar uma folha de estilo é feito sem tocar no HTML.
Se precisar atualizar dinamicamente o título da página com base no conteúdo, você pode usar a API document.title
do navegador. Para cenários mais complexos, quando você deseja alterar o título dos componentes React, você pode usar React Helmet, uma biblioteca de terceiros.
Se você usa um servidor personalizado para seu aplicativo em produção e deseja modificar o título antes que ele seja enviado ao navegador, siga os conselhos desta seção. Alternativamente, você pode pré-construir cada página como um arquivo HTML estático que carrega o pacote JavaScript, que é abordado aqui.
O projeto gerado inclui React e ReactDOM como dependências. Também inclui um conjunto de scripts usados pelo Create React App como uma dependência de desenvolvimento. Você pode instalar outras dependências (por exemplo, React Router) com npm
:
npm install --save react-router
Alternativamente, você pode usar yarn
:
yarn add react-router
Isso funciona para qualquer biblioteca, não apenas para react-router
.
Esta configuração de projeto suporta módulos ES6 graças ao Babel.
Embora você ainda possa usar require()
e module.exports
, recomendamos que você use import
e export
.
Por exemplo:
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 ;
Esteja ciente da diferença entre exportações padrão e nomeadas. É uma fonte comum de erros.
Sugerimos que você continue usando importações e exportações padrão quando um módulo exporta apenas uma única coisa (por exemplo, um componente). Isso é o que você obtém quando usa export default Button
e import Button from './Button'
.
As exportações nomeadas são úteis para módulos utilitários que exportam diversas funções. Um módulo pode ter no máximo uma exportação padrão e quantas exportações nomeadas desejar.
Saiba mais sobre os módulos ES6:
Em vez de baixar o aplicativo inteiro antes que os usuários possam usá-lo, a divisão de código permite dividir seu código em pequenos pedaços que você pode carregar sob demanda.
Esta configuração do projeto oferece suporte à divisão de código por meio de import()
dinâmico. Sua proposta está no estágio 3. A forma de função import()
toma o nome do módulo como argumento e retorna uma Promise
que sempre resolve para o objeto namespace do módulo.
Aqui está um exemplo:
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 ;
Isso fará com que moduleA.js
e todas as suas dependências exclusivas sejam um bloco separado que só é carregado depois que o usuário clica no botão 'Carregar'.
Você também pode usá-lo com sintaxe async
/ await
, se preferir.
Se você estiver usando o React Router, confira este tutorial sobre como usar a divisão de código com ele. Você pode encontrar o repositório GitHub complementar aqui.
Verifique também a seção Divisão de código na documentação do React.
Esta configuração do projeto usa Webpack para lidar com todos os ativos. O Webpack oferece uma maneira personalizada de “estender” o conceito de import
além do JavaScript. Para expressar que um arquivo JavaScript depende de um arquivo CSS, você precisa importar o CSS do arquivo 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" /> ;
}
}
Isso não é necessário para o React , mas muitas pessoas acham esse recurso conveniente. Você pode ler sobre os benefícios dessa abordagem aqui. No entanto, você deve estar ciente de que isso torna seu código menos portável para outras ferramentas e ambientes de construção que não o Webpack.
No desenvolvimento, expressar dependências dessa forma permite que seus estilos sejam recarregados instantaneamente conforme você os edita. Na produção, todos os arquivos CSS serão concatenados em um único arquivo .css
reduzido na saída do build.
Se você está preocupado em usar a semântica específica do Webpack, você pode colocar todo o seu CSS diretamente em src/index.css
. Ele ainda seria importado de src/index.js
, mas você sempre poderá remover essa importação se migrar posteriormente para uma ferramenta de construção diferente.
Esta configuração do projeto minimiza seu CSS e adiciona prefixos de fornecedor automaticamente por meio do Autoprefixer para que você não precise se preocupar com isso.
Por exemplo, isto:
. App {
display : flex;
flex-direction : row;
align-items : center;
}
fica assim:
. 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;
}
Se você precisar desabilitar o prefixo automático por algum motivo, siga esta seção.
Geralmente, recomendamos que você não reutilize as mesmas classes CSS em componentes diferentes. Por exemplo, em vez de usar uma classe CSS .Button
nos componentes <AcceptButton>
e <RejectButton>
, recomendamos criar um componente <Button>
com seus próprios estilos .Button
, que tanto <AcceptButton>
quanto <RejectButton>
possam renderizar (mas não herdar).
Seguir esta regra muitas vezes torna os pré-processadores CSS menos úteis, pois recursos como mixins e aninhamento são substituídos pela composição de componentes. Você pode, no entanto, integrar um pré-processador CSS se achar que é valioso. Neste passo a passo usaremos Sass, mas você também pode usar Less ou outra alternativa.
Primeiro, vamos instalar a interface de linha de comando do Sass:
npm install --save node-sass-chokidar
Alternativamente, você pode usar yarn
:
yarn add node-sass-chokidar
Em seguida, em package.json
, adicione as seguintes linhas aos scripts
:
"scripts": {
+ "build-css": "node-sass-chokidar src/ -o src/",
+ "watch-css": "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test --env=jsdom",
Nota: Para usar um pré-processador diferente, substitua os comandos
build-css
ewatch-css
de acordo com a documentação do seu pré-processador.
Agora você pode renomear src/App.css
para src/App.scss
e executar npm run watch-css
. O observador encontrará cada arquivo Sass nos subdiretórios src
e criará um arquivo CSS correspondente próximo a ele, em nosso caso substituindo src/App.css
. Como src/App.js
ainda importa src/App.css
, os estilos se tornam parte do seu aplicativo. Agora você pode editar src/App.scss
e src/App.css
será regenerado.
Para compartilhar variáveis entre arquivos Sass, você pode usar importações Sass. Por exemplo, src/App.scss
e outros arquivos de estilo de componente podem incluir @import "./shared.scss";
com definições de variáveis.
Para permitir a importação de arquivos sem usar caminhos relativos, você pode adicionar a opção --include-path
ao comando em 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",
Isso permitirá que você faça importações como
@import ' styles/_colors.scss ' ; // assuming a styles directory under src/
@import ' nprogress/nprogress ' ; // importing a css file from the nprogress node module
Neste ponto, você pode querer remover todos os arquivos CSS do controle de origem e adicionar src/**/*.css
ao seu arquivo .gitignore
. Geralmente é uma boa prática manter os produtos de construção fora do controle de origem.
Como etapa final, você pode achar conveniente executar watch-css
automaticamente com npm start
e executar build-css
como parte de npm run build
. Você pode usar o operador &&
para executar dois scripts sequencialmente. No entanto, não existe uma maneira multiplataforma de executar dois scripts em paralelo, então instalaremos um pacote para isso:
npm install --save npm-run-all
Alternativamente, você pode usar yarn
:
yarn add npm-run-all
Então podemos alterar os scripts start
e build
para incluir os comandos do pré-processador 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"
}
Agora, executar npm start
e npm run build
também cria arquivos Sass.
Por que node-sass-chokidar
?
node-sass
foi relatado como tendo os seguintes problemas:
Foi relatado que node-sass --watch
apresenta problemas de desempenho em certas condições quando usado em uma máquina virtual ou com docker.
Compilação de estilos infinitos #1939
node-sass
foi relatado como tendo problemas com a detecção de novos arquivos em um diretório #1891
node-sass-chokidar
é usado aqui porque aborda esses problemas.
Com o Webpack, o uso de ativos estáticos como imagens e fontes funciona de forma semelhante ao CSS.
Você pode import
um arquivo diretamente em um módulo JavaScript . Isso diz ao Webpack para incluir esse arquivo no pacote. Ao contrário das importações de CSS, a importação de um arquivo fornece um valor de string. Este valor é o caminho final que você pode referenciar em seu código, por exemplo, como o atributo src
de uma imagem ou o href
de um link para um PDF.
Para reduzir o número de solicitações ao servidor, a importação de imagens com menos de 10.000 bytes retorna um URI de dados em vez de um caminho. Isso se aplica às seguintes extensões de arquivo: bmp, gif, jpg, jpeg e png. Os arquivos SVG foram excluídos devido ao #1153.
Aqui está um exemplo:
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 ;
Isso garante que quando o projeto for compilado, o Webpack moverá corretamente as imagens para a pasta de construção e nos fornecerá os caminhos corretos.
Isso também funciona em CSS:
. Logo {
background-image : url (. / logo.png);
}
O Webpack encontra todas as referências relativas aos módulos em CSS (elas começam com ./
) e as substitui pelos caminhos finais do pacote compilado. Se você cometer um erro de digitação ou excluir acidentalmente um arquivo importante, verá um erro de compilação, assim como ao importar um módulo JavaScript inexistente. Os nomes de arquivos finais no pacote compilado são gerados pelo Webpack a partir de hashes de conteúdo. Se o conteúdo do arquivo mudar no futuro, o Webpack dará a ele um nome diferente na produção para que você não precise se preocupar com o armazenamento em cache de ativos a longo prazo.
Informamos que este também é um recurso personalizado do Webpack.
Não é obrigatório para o React , mas muitas pessoas gostam dele (e o React Native usa um mecanismo semelhante para imagens).
Uma forma alternativa de lidar com ativos estáticos é descrita na próxima seção.
public
Nota: este recurso está disponível com
[email protected]
e superior.
A pasta public
contém o arquivo HTML para que você possa ajustá-lo, por exemplo, para definir o título da página. A tag <script>
com o código compilado será adicionada automaticamente durante o processo de construção.
Você também pode adicionar outros ativos à pasta public
.
Observe que normalmente recomendamos que você import
ativos em arquivos JavaScript. Por exemplo, consulte as seções sobre como adicionar uma folha de estilo e como adicionar imagens e fontes. Este mecanismo oferece vários benefícios:
No entanto, existe uma saída de emergência que você pode usar para adicionar um ativo fora do sistema de módulo.
Se você colocar um arquivo na pasta public
, ele não será processado pelo Webpack. Em vez disso, ele será copiado para a pasta de construção intacto. Para fazer referência a ativos na pasta public
, você precisa usar uma variável especial chamada PUBLIC_URL
.
Dentro de index.html
, você pode usá-lo assim:
< link rel =" shortcut icon " href =" %PUBLIC_URL%/favicon.ico " >
Somente arquivos dentro da pasta public
estarão acessíveis pelo prefixo %PUBLIC_URL%
. Se precisar usar um arquivo de src
ou node_modules
, você terá que copiá-lo para especificar explicitamente sua intenção de tornar esse arquivo parte da compilação.
Quando você executa npm run build
, Create React App substituirá %PUBLIC_URL%
por um caminho absoluto correto para que seu projeto funcione mesmo se você usar roteamento do lado do cliente ou hospedá-lo em uma URL não raiz.
No código JavaScript, você pode usar process.env.PUBLIC_URL
para fins semelhantes:
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' } /> ;
}
Tenha em mente as desvantagens desta abordagem:
public
é pós-processado ou reduzido.public
Normalmente recomendamos importar folhas de estilo, imagens e fontes de JavaScript. A pasta public
é útil como solução alternativa para vários casos menos comuns:
manifest.webmanifest
.pace.js
fora do código incluído.<script>
. Observe que se você adicionar um <script>
que declare variáveis globais, você também precisará ler a próxima seção sobre como usá-las.
Quando você inclui um script no arquivo HTML que define variáveis globais e tenta usar uma dessas variáveis no código, o linter irá reclamar porque não consegue ver a definição da variável.
Você pode evitar isso lendo explicitamente a variável global do objeto window
, por exemplo:
const $ = window . $ ;
Isso torna óbvio que você está usando uma variável global intencionalmente e não por causa de um erro de digitação.
Alternativamente, você pode forçar o linter a ignorar qualquer linha adicionando // eslint-disable-line
depois dela.
Você não precisa usar o React Bootstrap junto com o React, mas é uma biblioteca popular para integrar o Bootstrap com aplicativos React. Se precisar, você pode integrá-lo ao aplicativo Create React seguindo estas etapas:
Instale React Bootstrap e Bootstrap do npm. React Bootstrap não inclui Bootstrap CSS, então também precisa ser instalado:
npm install --save react-bootstrap bootstrap@3
Alternativamente, você pode usar yarn
:
yarn add react-bootstrap bootstrap@3
Importe CSS do Bootstrap e, opcionalmente, CSS do tema Bootstrap no início do seu arquivo src/index.js
:
import 'bootstrap/dist/css/bootstrap.css' ;
import 'bootstrap/dist/css/bootstrap-theme.css' ;
// Put any other imports below so that CSS from your
// components takes precedence over default styles.
Importe os componentes necessários do React Bootstrap no arquivo src/App.js
ou nos arquivos de componentes personalizados:
import { Navbar , Jumbotron , Button } from 'react-bootstrap' ;
Agora você está pronto para usar os componentes importados do React Bootstrap em sua hierarquia de componentes definida no método render. Aqui está um exemplo de App.js
refeito usando React Bootstrap.
Às vezes você pode precisar ajustar os estilos visuais do Bootstrap (ou pacote equivalente).
Sugerimos a seguinte abordagem:
Aqui está um exemplo de adição de um Bootstrap personalizado que segue estas etapas.
Flow é um verificador de tipo estático que ajuda você a escrever código com menos bugs. Confira esta introdução ao uso de tipos estáticos em JavaScript se você for novo nesse conceito.
Versões recentes do Flow funcionam com projetos Create React App prontos para uso.
Para adicionar Flow a um projeto Create React App, siga estas etapas:
npm install --save flow-bin
(ou yarn add flow-bin
)."flow": "flow"
à seção scripts
do seu package.json
.npm run flow init
(ou yarn flow init
) para criar um arquivo .flowconfig
no diretório raiz.// @flow
a todos os arquivos que você deseja digitar check (por exemplo, para src/App.js
). Agora você pode executar npm run flow
(ou yarn flow
) para verificar se há erros de tipo nos arquivos. Opcionalmente, você pode usar um IDE como o Nuclide para uma melhor experiência integrada. No futuro, planejamos integrá-lo ainda mais estreitamente ao Create React App.
Para saber mais sobre o Flow, confira sua documentação.
Create React App não prescreve uma solução de roteamento específica, mas React Router é a mais popular.
Para adicioná-lo, execute:
npm install --save react-router-dom
Alternativamente, você pode usar yarn
:
yarn add react-router-dom
Para experimentar, exclua todo o código em src/App.js
e substitua-o por qualquer um dos exemplos em seu site. O Exemplo Básico é um bom lugar para começar.
Observe que pode ser necessário configurar seu servidor de produção para oferecer suporte ao roteamento do lado do cliente antes de implantar seu aplicativo.
Nota: este recurso está disponível com
[email protected]
e superior.
Seu projeto pode consumir variáveis declaradas em seu ambiente como se tivessem sido declaradas localmente em seus arquivos JS. Por padrão, você terá NODE_ENV
definido para você e quaisquer outras variáveis de ambiente começando com REACT_APP_
.
As variáveis de ambiente são incorporadas durante o tempo de construção . Como o Create React App produz um pacote HTML/CSS/JS estático, ele não pode lê-los em tempo de execução. Para lê-los em tempo de execução, você precisaria carregar o HTML na memória do servidor e substituir os espaços reservados em tempo de execução, conforme descrito aqui. Alternativamente, você pode reconstruir o aplicativo no servidor sempre que alterá-los.
Nota: Você deve criar variáveis de ambiente customizadas começando com
REACT_APP_
. Quaisquer outras variáveis, excetoNODE_ENV
serão ignoradas para evitar a exposição acidental de uma chave privada na máquina que possa ter o mesmo nome. A alteração de quaisquer variáveis de ambiente exigirá que você reinicie o servidor de desenvolvimento, se ele estiver em execução.
Essas variáveis de ambiente serão definidas para você em process.env
. Por exemplo, ter uma variável de ambiente chamada REACT_APP_SECRET_CODE
será exposta em seu JS como process.env.REACT_APP_SECRET_CODE
.
Há também uma variável de ambiente integrada especial chamada NODE_ENV
. Você pode lê-lo em process.env.NODE_ENV
. Quando você executa npm start
, é sempre igual a 'development'
, quando você executa npm test
é sempre igual a 'test'
, e quando você executa npm run build
para criar um pacote de produção, é sempre igual a 'production'
. Você não pode substituir NODE_ENV
manualmente. Isso evita que os desenvolvedores implantem acidentalmente uma compilação de desenvolvimento lenta na produção.
Essas variáveis de ambiente podem ser úteis para exibir informações condicionalmente com base em onde o projeto está implantado ou para consumir dados confidenciais que estão fora do controle de versão.
Primeiro, você precisa ter variáveis de ambiente definidas. Por exemplo, digamos que você queira consumir um segredo definido no ambiente dentro de um <form>
:
render ( ) {
return (
< div >
< small > You are running this application in < b > { process . env . NODE_ENV } </ b > mode. </ small >
< form >
< input type = "hidden" defaultValue = { process . env . REACT_APP_SECRET_CODE } />
</ form >
</ div >
) ;
}
Durante a construção, process.env.REACT_APP_SECRET_CODE
será substituído pelo valor atual da variável de ambiente REACT_APP_SECRET_CODE
. Lembre-se de que a variável NODE_ENV
será definida automaticamente para você.
Ao carregar o aplicativo no navegador e inspecionar <input>
, você verá seu valor definido como abcdef
, e o texto em negrito mostrará o ambiente fornecido ao usar npm start
:
< div >
< small > You are running this application in < b > development </ b > mode. </ small >
< form >
< input type =" hidden " value =" abcdef " />
</ form >
</ div >
O formulário acima procura uma variável chamada REACT_APP_SECRET_CODE
do ambiente. Para consumir esse valor, precisamos tê-lo definido no ambiente. Isso pode ser feito de duas maneiras: em seu shell ou em um arquivo .env
. Ambas as formas são descritas nas próximas seções.
Ter acesso ao NODE_ENV
também é útil para executar ações condicionalmente:
if ( process . env . NODE_ENV !== 'production' ) {
analytics . disable ( ) ;
}
Quando você compila o aplicativo com npm run build
, a etapa de minificação eliminará essa condição e o pacote resultante será menor.
Nota: este recurso está disponível com
[email protected]
e superior.
Você também pode acessar as variáveis de ambiente começando com REACT_APP_
em public/index.html
. Por exemplo:
< title > %REACT_APP_WEBSITE_NAME% </ title >
Observe que as advertências da seção acima se aplicam:
NODE_ENV
e PUBLIC_URL
), os nomes das variáveis devem começar com REACT_APP_
para funcionar.A definição de variáveis de ambiente pode variar entre sistemas operacionais. Também é importante saber que essa maneira é temporária durante a duração da sessão do shell.
set " REACT_APP_SECRET_CODE = abcdef " && npm start
(Observação: aspas em torno da atribuição da variável são necessárias para evitar espaços em branco no final.)
( $ env: REACT_APP_SECRET_CODE = " abcdef " ) -and (npm start)
REACT_APP_SECRET_CODE=abcdef npm start
.env
Nota: este recurso está disponível com
[email protected]
e superior.
Para definir variáveis de ambiente permanentes, crie um arquivo chamado .env
na raiz do seu projeto:
REACT_APP_SECRET_CODE=abcdef
Nota: Você deve criar variáveis de ambiente customizadas começando com
REACT_APP_
. Quaisquer outras variáveis, excetoNODE_ENV
serão ignoradas para evitar a exposição acidental de uma chave privada na máquina que possa ter o mesmo nome. A alteração de quaisquer variáveis de ambiente exigirá que você reinicie o servidor de desenvolvimento, se ele estiver em execução.
Os arquivos .env
devem ser verificados no controle de origem (com a exclusão de .env*.local
).
.env
podem ser usados?Nota: este recurso está disponível com
[email protected]
e superior .
.env
: Padrão..env.local
: substituições locais. Este arquivo é carregado para todos os ambientes, exceto teste..env.development
, .env.test
, .env.production
: configurações específicas do ambiente..env.development.local
, .env.test.local
, .env.production.local
: substituições locais de configurações específicas do ambiente.Os arquivos à esquerda têm mais prioridade que os arquivos à direita:
npm start
: .env.development.local
, .env.development
, .env.local
, .env
npm run build
: .env.production.local
, .env.production
, .env.local
, .env
npm test
: .env.test.local
, .env.test
, .env
(nota .env.local
está faltando) Essas variáveis funcionarão como os padrões se a máquina não as definir explicitamente.
Consulte a documentação do DOTENV para obter mais detalhes.
NOTA: Se você estiver definindo variáveis de ambiente para desenvolvimento, sua plataforma de CI e/ou hospedagem provavelmente também precisará disso. Consulte a documentação de como fazer isso. Por exemplo, consulte a documentação para Travis CI ou Heroku.
.env
Nota: Este recurso está disponível com
[email protected]
e superior.
Expanda as variáveis já em sua máquina para uso no seu arquivo .env
(usando dotenv-expand).
Por exemplo, para obter a variável de ambiente npm_package_version
:
REACT_APP_VERSION=$npm_package_version
# also works:
# REACT_APP_VERSION=${npm_package_version}
Ou expandir variáveis locais para o arquivo .env
atual:
DOMAIN=www.example.com
REACT_APP_FOO=$DOMAIN/foo
REACT_APP_BAR=$DOMAIN/bar
Muitas bibliotecas populares usam decoradores em sua documentação.
Create React App não suporta a sintaxe do decorador no momento porque:
No entanto, em muitos casos, você pode reescrever o código baseado em decoradores sem decoradores igualmente bom.
Consulte estes dois tópicos para referência:
Create React App adicionará suporte ao decorador quando a especificação avançar para um estágio estável.
O React não prescreve uma abordagem específica para buscar dados, mas as pessoas geralmente usam uma biblioteca como Axios ou a API fetch()
fornecida pelo navegador. Convenientemente, o aplicativo Create React inclui um poli -preenchimento para fetch()
para que você possa usá -lo sem se preocupar com o suporte do navegador.
A função Global fetch
permite fazer facilmente solicitações de AJAX. Ele assume um URL como uma entrada e retorna uma Promise
que resolve a um objeto Response
. Você pode encontrar mais informações sobre fetch
aqui.
Este projeto também inclui um Polyfill Promise que fornece uma implementação completa de promessas/a+. Uma promessa representa o resultado eventual de uma operação assíncrona, você pode encontrar mais informações sobre as promessas aqui e aqui. Axios e fetch()
usam promessas sob o capô. Você também pode usar a sintaxe async / await
para reduzir o ninho de retorno de chamada.
Você pode aprender mais sobre como fazer solicitações de Ajax dos componentes do React na entrada de perguntas frequentes no site do React.
Esses tutoriais ajudarão você a integrar seu aplicativo com um back -end da API em outra porta, usando fetch()
para acessá -lo.
Confira este tutorial. Você pode encontrar o repositório do Companion Github aqui.
Confira este tutorial. Você pode encontrar o repositório do Companion Github aqui.
Nota: Este recurso está disponível com
[email protected]
e superior.
As pessoas costumam servir o aplicativo React front-end do mesmo host e porta que sua implementação de back-end.
Por exemplo, uma configuração de produção pode ser assim depois que o aplicativo for implantado:
/ - 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
Essa configuração não é necessária. No entanto, se você tiver uma configuração como essa, é conveniente escrever solicitações como fetch('/api/todos')
sem se preocupar em redirecioná -las para outro host ou porta durante o desenvolvimento.
Para dizer ao servidor de desenvolvimento para proxy qualquer solicitação desconhecida ao seu servidor de API em desenvolvimento, adicione um campo proxy
ao seu package.json
, por exemplo:
"proxy" : "http://localhost:4000" ,
Dessa forma, quando você fetch('/api/todos')
em desenvolvimento, o servidor de desenvolvimento reconhecerá que não é um ativo estático e procurará sua solicitação para http://localhost:4000/api/todos
como fallback. O servidor de desenvolvimento só tentará enviar solicitações sem text/html
em seu cabeçalho Accept
para o proxy.
Convenientemente, isso evita problemas de CORS e mensagens de erro como esta no desenvolvimento:
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.
Lembre -se de que proxy
só tem efeito no desenvolvimento (com npm start
), e cabe a você garantir que os URLs como /api/todos
apontem para a coisa certa na produção. Você não precisa usar o prefixo /api
. Qualquer solicitação não reconhecida sem um cabeçalho text/html
será redirecionada para o proxy
especificado.
A opção proxy
suporta conexões HTTP, HTTPS e WebSocket.
Se a opção proxy
não for flexível o suficiente para você, alternativamente, você pode:
Ao ativar a opção proxy
, você opta em um conjunto mais rigoroso de verificações de host. Isso é necessário porque deixar o back -end aberta a hosts remotos torna seu computador vulnerável a ataques de renovação do DNS. A questão é explicada neste artigo e nesta questão.
Isso não deve afetá -lo ao desenvolver no localhost
, mas se você se desenvolver remotamente como descrito aqui, verá esse erro no navegador depois de ativar a opção proxy
:
Cabeçalho do host inválido
Para contorná -lo, você pode especificar seu host de desenvolvimento público em um arquivo chamado .env.development
na raiz do seu projeto:
HOST=mypublicdevhost.com
Se você reiniciar o servidor de desenvolvimento agora e carregar o aplicativo do host especificado, ele deve funcionar.
Se você ainda estiver com problemas ou se estiver usando um ambiente mais exótico como um editor de nuvem, pode ignorar completamente a verificação do host adicionando uma linha ao .env.development.local
. Observe que isso é perigoso e expõe sua máquina à execução remota de código de sites maliciosos:
# NOTE: THIS IS DANGEROUS!
# It exposes your machine to attacks from the websites you visit.
DANGEROUSLY_DISABLE_HOST_CHECK=true
Não recomendamos essa abordagem.
Nota: Este recurso está disponível com
[email protected]
e superior.
Se a opção proxy
não for flexível o suficiente para você, você poderá especificar um objeto na forma a seguir (no package.json
).
Você também pode especificar qualquer valor de configuração http-proxy-middleware
ou http-proxy
.
{
// ...
"proxy" : {
"/api" : {
"target" : "<url>" ,
"ws" : true
// ...
}
}
// ...
}
Todas as solicitações correspondentes a esse caminho serão proxies, sem exceções. Isso inclui solicitações de text/html
, que a opção proxy
padrão não proxy.
Se você precisar especificar vários proxies, poderá fazê -lo especificando entradas adicionais. As correspondências são expressões regulares, para que você possa usar um regexp para corresponder a vários caminhos.
{
// ...
"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>"
// ...
}
}
// ...
}
Ao configurar um proxy do WebSocket, existem algumas considerações extras a serem cientes.
Se você estiver usando um mecanismo WebSocket como o Socket.io, deve ter um servidor Socket.io em execução que pode usar como o alvo proxy. O Socket.io não funcionará com um servidor WebSocket padrão. Especificamente, não espere que o Socket.io trabalhe com o teste de eco websocket.org.
Há uma boa documentação disponível para configurar um servidor Socket.io.
O WebSockets padrão funcionará com um servidor WebSocket padrão, bem como o teste WebSocket.org Echo. Você pode usar bibliotecas como o WS para o servidor, com WebSockets nativos no navegador.
De qualquer maneira, você pode proxy WebSocket Solictações manualmente no package.json
:
{
// ...
"proxy" : {
"/socket" : {
// Your compatible WebSocket server
"target" : "ws://<socket_url>" ,
// Tell http-proxy-middleware that this is a WebSocket proxy.
// Also allows you to proxy WebSocket requests without an additional HTTP request
// https://github.com/chimurai/http-proxy-middleware#external-websocket-upgrade
"ws" : true
// ...
}
}
// ...
}
Nota: Este recurso está disponível com
[email protected]
e superior.
Você pode exigir que o servidor de dev sirva páginas sobre o HTTPS. Um caso específico em que isso pode ser útil é o uso do recurso "proxy" para solicitações de proxy para um servidor de API quando esse servidor de API está servindo HTTPS.
Para fazer isso, defina a variável de ambiente HTTPS
como true
e inicie o servidor dev, como de costume, com npm start
:
set HTTPS = true && npm start
( $ env: HTTPS = $true ) -and (npm start)
(Nota: a falta de espaço em branco é intencional.)
HTTPS=true npm start
Observe que o servidor usará um certificado autoassinado; portanto, seu navegador da Web quase definitivamente exibirá um aviso ao acessar a página.
<meta>
no servidor Como o aplicativo Create React não suporta a renderização do servidor, você pode estar se perguntando como fazer <meta>
tags dinâmico e refletir o URL atual. Para resolver isso, recomendamos adicionar espaços reservados ao HTML, como este:
<!doctype html >
< html lang =" en " >
< head >
< meta property =" og:title " content =" __OG_TITLE__ " >
< meta property =" og:description " content =" __OG_DESCRIPTION__ " >
Em seguida, no servidor, independentemente do back -end que você usa, você pode ler index.html
na memória e substituir __OG_TITLE__
, __OG_DESCRIPTION__
e quaisquer outros espaços reservados com valores, dependendo do URL atual. Apenas certifique -se de higienizar e escapar dos valores interpolados para que eles sejam seguros para incorporar -se ao HTML!
Se você usar um servidor de nó, poderá compartilhar a lógica de correspondência de rota entre o cliente e o servidor. No entanto, duplicar também funciona bem em casos simples.
Se você estiver hospedando sua build
com um provedor de hospedagem estática, poderá usar o React-Snapshot ou o React-SNAP para gerar páginas HTML para cada rota ou link relativo em seu aplicativo. Essas páginas se tornarão perfeitamente ativas ou "hidratadas" quando o pacote JavaScript estiver carregado.
Há também oportunidades de usar isso fora da hospedagem estática, para tirar a pressão do servidor ao gerar rotas de cache.
O principal benefício da pré-renderização é que você obtém o conteúdo principal de cada página com a carga útil HTML-indefinindo se o seu pacote JavaScript com sucesso. Também aumenta a probabilidade de que cada rota do seu aplicativo seja retirada pelos mecanismos de pesquisa.
Você pode ler mais sobre a pré-renderização de configuração zero (também chamada de instantâneo) aqui.
Da mesma forma a seção anterior, você pode deixar alguns espaços reservados no HTML que injetam variáveis globais, por exemplo:
< ! doctype html >
< html lang = "en" >
< head >
< script >
window.SERVER_DATA = __SERVER_DATA__;
</ script >
Em seguida, no servidor, você pode substituir __SERVER_DATA__
por um JSON de dados reais antes de enviar a resposta. O código do cliente pode ler window.SERVER_DATA
para usá -lo. Certifique -se de higienizar o JSON antes de enviá -lo ao cliente, pois torna seu aplicativo vulnerável aos ataques XSS.
Nota: Este recurso está disponível com
[email protected]
e superior.
Leia o Guia de Migração para aprender como habilitá -lo em projetos mais antigos!
Create React App usa o JEST como seu corredor de teste. Para se preparar para essa integração, fizemos uma grande reformulação de brincadeiras, por isso, se você ouviu coisas ruins sobre isso anos atrás, experimente.
JEST é um corredor baseado em nós. Isso significa que os testes sempre são executados em um ambiente de nós e não em um navegador real. Isso nos permite ativar a velocidade de iteração rápida e impedir descamação.
Enquanto o JEST fornece globais de navegador, como window
graças ao JSDOM, eles são apenas aproximações do comportamento real do navegador. O JEST deve ser usado para testes de unidade de sua lógica e seus componentes, em vez das peculiaridades do DOM.
Recomendamos que você use uma ferramenta separada para testes de ponta a ponta do navegador, se precisar deles. Eles estão além do escopo do Create React App.
O JEST procurará arquivos de teste com qualquer uma das seguintes convenções de nomeação popular:
.js
em pastas __tests__
..test.js
..spec.js
. Os arquivos .test.js
/ .spec.js
(ou as pastas __tests__
) podem estar localizados em qualquer profundidade na pasta de nível superior src
.
Recomendamos colocar os arquivos de teste (ou pastas __tests__
) ao lado do código que estão testando para que as importações relativas pareçam mais curtas. Por exemplo, se App.test.js
e App.js
estiverem na mesma pasta, o teste só precisará import App from './App'
em vez de um longo caminho relativo. A classificação também ajuda a encontrar testes mais rapidamente em projetos maiores.
Quando você executa npm test
, o JEST será lançado no modo de relógio. Toda vez que você salva um arquivo, ele executa novamente os testes, assim como npm start
recompila o código.
O observador inclui uma interface interativa da linha de comando com a capacidade de executar todos os testes ou se concentrar em um padrão de pesquisa. Ele foi projetado dessa maneira para que você possa mantê-lo aberto e desfrutar de re-reeu. Você pode aprender os comandos com o "Uso da vigilância", observe que o vigia imprime após cada execução:
Por padrão, quando você executa npm test
, o JEST executará apenas os testes relacionados aos arquivos alterados desde a última confirmação. Esta é uma otimização projetada para fazer seus testes funcionarem rapidamente, independentemente de quantos testes você tenha. No entanto, assume que você não costuma cometer o código que não passa nos testes.
O JEST sempre mencionará explicitamente que apenas executou testes relacionados aos arquivos alterados desde a última confirmação. Você também pode pressionar a
modo de relógio para forçar a JEST para executar todos os testes.
O JEST sempre executará todos os testes em um servidor de integração contínuo ou se o projeto não estiver dentro de um repositório Git ou Mercurial.
Para criar testes, adicione it()
(ou test()
) com o nome do teste e seu código. Opcionalmente, você pode envolvê -los em blocos describe()
para agrupamento lógico, mas isso não é necessário nem recomendado.
O JEST fornece uma função global expect()
para fazer afirmações. Um teste básico pode ser assim:
import sum from './sum' ;
it ( 'sums numbers' , ( ) => {
expect ( sum ( 1 , 2 ) ) . toEqual ( 3 ) ;
expect ( sum ( 2 , 2 ) ) . toEqual ( 4 ) ;
} ) ;
Todos os Matcores expect()
suportados pelo JEST estão extensivamente documentados aqui.
Você também pode usar jest.fn()
e expect(fn).toBeCalled()
para criar "espiões" ou zombar funções.
Há um amplo espectro de técnicas de teste de componentes. Eles variam de um "teste de fumaça", verificando que um componente renderiza sem arremessar, a renderização e testar rasos parte da saída, para renderizar e testar o ciclo de vida do componente e as mudanças de estado.
Diferentes projetos escolhem diferentes trocas de teste com base na frequência com que os componentes mudam e quanta lógica eles contêm. Se você ainda não decidiu uma estratégia de teste, recomendamos que você comece a criar testes simples de fumaça para seus componentes:
import React from 'react' ;
import ReactDOM from 'react-dom' ;
import App from './App' ;
it ( 'renders without crashing' , ( ) => {
const div = document . createElement ( 'div' ) ;
ReactDOM . render ( < App /> , div ) ;
} ) ;
Este teste monta um componente e garante que ele não jogue durante a renderização. Testes como esse oferecem muito valor com muito pouco esforço, para que sejam ótimos como ponto de partida, e este é o teste que você encontrará no src/App.test.js
.
Quando você encontra bugs causados pela alteração dos componentes, você obterá uma visão mais profunda sobre quais partes deles valem a pena testar em seu aplicativo. Pode ser um bom momento para introduzir testes mais específicos, afirmando a saída ou comportamento esperado.
Se você deseja testar componentes isolados dos componentes filhos que eles renderizam, recomendamos o uso da API de renderização shallow()
da enzima. Para instalá -lo, execute:
npm install --save enzyme enzyme-adapter-react-16 react-test-renderer
Como alternativa, você pode usar yarn
:
yarn add enzyme enzyme-adapter-react-16 react-test-renderer
A partir da enzima 3, você precisará instalar a enzima junto com um adaptador correspondente à versão do React que você está usando. (Os exemplos acima usam o adaptador para o React 16.)
O adaptador também precisará ser configurado em seu arquivo de configuração global:
src/setupTests.js
import { configure } from 'enzyme' ;
import Adapter from 'enzyme-adapter-react-16' ;
configure ( { adapter : new Adapter ( ) } ) ;
NOTA: Lembre -se de que, se você decidir "ejetar" antes de criar
src/setupTests.js
, o arquivopackage.json
resultante não conterá nenhuma referência a ele. Leia aqui para aprender como adicionar isso após a ejetar.
Agora você pode escrever um teste de fumaça com ele:
import React from 'react' ;
import { shallow } from 'enzyme' ;
import App from './App' ;
it ( 'renders without crashing' , ( ) => {
shallow ( < App /> ) ;
} ) ;
Ao contrário do teste de fumaça anterior usando ReactDOM.render()
, este teste apenas renderiza <App>
e não se aprofunda. Por exemplo, mesmo se <App>
renderize um <Button>
que joga, esse teste passará. A renderização rasa é ótima para testes de unidade isolados, mas você ainda pode criar alguns testes completos de renderização para garantir que os componentes se integrem corretamente. A enzima suporta a renderização completa com mount()
e você também pode usá -lo para testar as alterações do estado e o ciclo de vida do componente.
Você pode ler a documentação da enzima para obter mais técnicas de teste. A documentação da enzima usa chai e sinon para asserções, mas você não precisa usá-las porque o jest fornece espera expect()
e jest.fn()
para espiões.
Aqui está um exemplo da documentação enzimática que afirma que a saída específica, reescrita, para usar o Jest Matchers:
import React from 'react' ;
import { shallow } from 'enzyme' ;
import App from './App' ;
it ( 'renders welcome message' , ( ) => {
const wrapper = shallow ( < App /> ) ;
const welcome = < h2 > Welcome to React </ h2 > ;
// expect(wrapper.contains(welcome)).to.equal(true);
expect ( wrapper . contains ( welcome ) ) . toEqual ( true ) ;
} ) ;
Todos os fósforos de Jest estão extensivamente documentados aqui.
No entanto, você pode usar uma biblioteca de asserção de terceiros como o Chai, se quiser, conforme descrito abaixo.
Além disso, você pode achar a Jest-Enzyme útil para simplificar seus testes com partidas legíveis. O código acima contains
o código pode ser escrito mais simplesmente com a jest-enzima.
expect ( wrapper ) . toContainReact ( welcome )
Para ativar isso, instale jest-enzyme
:
npm install --save jest-enzyme
Como alternativa, você pode usar yarn
:
yarn add jest-enzyme
Importe -o no src/setupTests.js
para disponibilizar seus fósteadores em todos os testes:
import 'jest-enzyme' ;
Recomendamos que você use expect()
para asserções e jest.fn()
para espiões. Se você estiver tendo problemas com eles, arquive -os contra o brinde, e nós os corrigiremos. Pretendemos continuar tornando-os melhores para reagir, apoiando, por exemplo, elementos de reação de impressão bonita como JSX.
No entanto, se você estiver acostumado a outras bibliotecas, como Chai e Sinon, ou se você tiver código existente usando -os que deseja portar, poderá importá -los normalmente assim:
import sinon from 'sinon' ;
import { expect } from 'chai' ;
E então use -os em seus testes como você normalmente.
Nota: Este recurso está disponível com
[email protected]
e superior.
Se o seu aplicativo usar uma API do navegador que você precisará zombar dos seus testes ou se precisar apenas de uma configuração global antes de executar seus testes, adicione um src/setupTests.js
ao seu projeto. Ele será executado automaticamente antes de executar seus testes.
Por exemplo:
src/setupTests.js
const localStorageMock = {
getItem : jest . fn ( ) ,
setItem : jest . fn ( ) ,
clear : jest . fn ( )
} ;
global . localStorage = localStorageMock
NOTA: Lembre -se de que, se você decidir "ejetar" antes de criar
src/setupTests.js
, o arquivopackage.json
resultante não conterá nenhuma referência a ele; portanto, você deve criar manualmente o imóvelsetupTestFrameworkScriptFile
na configuração para jest, algo como o seguinte:
"jest" : { // ... "setupTestFrameworkScriptFile" : "<rootDir>/src/setupTests.js" }
Você pode substituí it()
por xit()
para excluir temporariamente um teste de ser executado.
Da mesma forma, fit()
permite que você se concentre em um teste específico sem executar outros testes.
O JEST possui um repórter de cobertura integrado que funciona bem com o ES6 e não requer configuração.
Execute npm test -- --coverage
(observe extra --
meio) para incluir um relatório de cobertura como este:
Observe que os testes são muito mais lentos com a cobertura, por isso é recomendável executá -lo separadamente do seu fluxo de trabalho normal.
A configuração padrão da cobertura do jest pode ser superestimada adicionando qualquer uma das seguintes teclas suportadas a uma configuração de jest no seu package.json.
Substituições suportadas:
collectCoverageFrom
coverageReporters
coverageThreshold
snapshotSerializers
Exemplo 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 " ]
}
}
Por padrão, npm test
executa o observador com a CLI interativa. No entanto, você pode forçá -lo a executar testes uma vez e terminar o processo definindo uma variável de ambiente chamada CI
.
Ao criar uma construção do seu aplicativo com os avisos npm run build
Linter, não são verificados por padrão. Assim como npm test
, você pode forçar a compilação a realizar uma verificação de aviso de linhagem, definindo a variável de ambiente CI
. Se algum aviso for encontrado, a construção falhará.
Os servidores de CI populares já definem a variável de ambiente CI
por padrão, mas você também pode fazer isso:
.travis.yml
ao seu repositório Git. language: node_js
node_js:
- 6
cache:
directories:
- node_modules
script:
- npm run build
- npm test
Siga este artigo para configurar o CircLeci com um projeto de aplicativo Create React.
set CI = true && npm test
set CI = true && npm run build
(Nota: a falta de espaço em branco é intencional.)
( $ env: CI = $true ) -and (npm test)
( $ env: CI = $true ) -and (npm run build)
CI=true npm test
CI=true npm run build
O comando de teste forçará o JEST a executar testes uma vez, em vez de iniciar o vigia.
Se você estiver fazendo isso com frequência em desenvolvimento, registre um problema para nos contar sobre o seu caso de uso, pois queremos tornar o Watcher a melhor experiência e está aberto a alterar a maneira como funciona para acomodar mais fluxos de trabalho.
O comando Build verificar se há avisos do Linter e falhará, se houver, for encontrado.
Por padrão, o package.json
do projeto gerado se parece com o seguinte:
"scripts" : {
"start" : "react-scripts start" ,
"build" : "react-scripts build" ,
"test" : "react-scripts test --env=jsdom"
Se você souber que nenhum de seus testes depende do JSDOM, você pode remover com segurança --env=jsdom
, e seus testes serão executados mais rápido:
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
- "test": "react-scripts test --env=jsdom"
+ "test": "react-scripts test"
Para ajudá -lo a se decidir, aqui está uma lista de APIs que precisam de JSDOM :
window
e document
ReactDOM.render()
TestUtils.renderIntoDocument()
(um atalho para o acima)mount()
na enzimaPor outro lado, o JSDOM não é necessário para as seguintes APIs:
TestUtils.createRenderer()
(renderização rasa)shallow()
na enzimaFinalmente, o JSDOM também não é necessário para testes de instantâneos.
O teste de instantâneo é um recurso do JEST que gera automaticamente instantâneos de texto de seus componentes e os salva no disco; Leia mais sobre o teste de instantâneos.
Se você usar o código do Visual Studio, existe uma extensão de jest que funciona com o aplicativo Create React pronta para uso. Isso fornece muitos recursos semelhantes ao IDE enquanto usa um editor de texto: mostrando o status de um teste executado com possíveis mensagens falhas embutidas, iniciando e interrompendo o vigia automaticamente e oferecendo atualizações de instantâneos com um clique.
Existem várias maneiras de configurar um depurador para seus testes de brincadeira. Cobrimos a depuração no código Chrome e Visual Studio.
Nota: Os testes de depuração requer o nó 8 ou superior.
Adicione o seguinte à seção scripts
no package.json
do seu projeto.json
"scripts" : {
"test:debug" : " react-scripts --inspect-brk test --runInBand --env=jsdom "
}
Coloque debugger;
declarações em qualquer teste e execução:
$ npm run test:debug
Isso começará a executar seus testes de brincadeira, mas pausará antes de executar para permitir que um depurador anexe ao processo.
Abra o seguinte no Chrome
about:inspect
Após abrir esse link, as ferramentas do desenvolvedor do Chrome serão exibidas. Selecione inspect
seu processo e um ponto de interrupção será definido na primeira linha do script React (isso é feito simplesmente para lhe dar tempo para abrir as ferramentas do desenvolvedor e impedir que o JEST seja executado antes de fazer tempo para fazê -lo). Clique no botão que se parece com um botão "play" no lado direito superior direito da tela para continuar a execução. Quando o JEST executar o teste que contém a declaração do depurador, a execução fará uma pausa e você pode examinar o escopo atual e chamar a pilha.
NOTA: A opção -RuninBand CLI garante que o JEST execute o teste no mesmo processo, em vez de processos de desova para testes individuais. Normalmente, o brinquedismo paraleliza o teste em processos, mas é difícil depurar muitos processos ao mesmo tempo.
Os testes de jest de depuração são suportados para fora da caixa para o código do Visual Studio.
Use o seguinte arquivo de configuração launch.json
:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug CRA Tests",
"type": "node",
"request": "launch",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/react-scripts",
"args": [
"test",
"--runInBand",
"--no-cache",
"--env=jsdom"
],
"cwd": "${workspaceRoot}",
"protocol": "inspector",
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
]
}
Geralmente, em um aplicativo, você tem muitos componentes da interface do usuário e cada um deles tem muitos estados diferentes. Para um exemplo, um componente simples de botão pode ter os seguintes estados:
Geralmente, é difícil ver esses estados sem executar um aplicativo de amostra ou alguns exemplos.
O aplicativo Create React não inclui nenhuma ferramenta para isso por padrão, mas você pode adicionar facilmente o Storybook para react (fonte) ou react styleguidist (origem) ao seu projeto. São ferramentas de terceiros que permitem desenvolver componentes e ver todos os seus estados isoladamente do seu aplicativo .
Você também pode implantar seu livro de histórias ou guia de estilo como um aplicativo estático. Dessa forma, todos em sua equipe podem visualizar e revisar diferentes estados de componentes da interface do usuário sem iniciar um servidor de back -end ou criar uma conta em seu aplicativo.
O Storybook é um ambiente de desenvolvimento para os componentes da interface do usuário do React. Ele permite navegar em uma biblioteca de componentes, visualizar os diferentes estados de cada componente e desenvolver e testar componentes interativamente.
Primeiro, instale o seguinte pacote NPM globalmente:
npm install -g @storybook/cli
Em seguida, execute o seguinte comando dentro do diretório do seu aplicativo:
getstorybook
Depois disso, siga as instruções na tela.
Saiba mais sobre o React Storybook:
O StyleGuidist combina um guia de estilo, onde todos os seus componentes são apresentados em uma única página com os exemplos de documentação e uso de adereços, com um ambiente para o desenvolvimento de componentes isoladamente, semelhante ao livro de histórias. No StyleGuidist, você escreve exemplos em Markdown, onde cada trecho de código é renderizado como um playground editável ao vivo.
Primeiro, instale o StyleGuidist:
npm install --save react-styleguidist
Como alternativa, você pode usar yarn
:
yarn add react-styleguidist
Em seguida, adicione esses scripts ao seu package.json
:
"scripts": {
+ "styleguide": "styleguidist server",
+ "styleguide:build": "styleguidist build",
"start": "react-scripts start",
Em seguida, execute o seguinte comando dentro do diretório do seu aplicativo:
npm run styleguide
Depois disso, siga as instruções na tela.
Saiba mais sobre o React StyleGuidist:
Create React App não fornece nenhuma funcionalidade interna para publicar um componente no NPM. Se você estiver pronto para extrair um componente do seu projeto para que outras pessoas possam usá -lo, recomendamos movê -lo para um diretório separado para fora do seu projeto e depois usar uma ferramenta como o NWB para prepará -lo para publicação.
Por padrão, a construção da produção é um aplicativo da Web progressivo totalmente funcional e offline.
Os aplicativos da Web progressivos são mais rápidos e confiáveis que as páginas da web tradicionais e fornecem uma experiência móvel envolvente:
O sw-precache-webpack-plugin
é integrado à configuração de produção e cuidará de um arquivo de trabalhador de serviço que precederá automaticamente todos os seus ativos locais e os manterá atualizados ao implantar atualizações. O trabalhador do serviço usará uma estratégia de cache primeiro para lidar com todos os pedidos de ativos locais, incluindo o HTML inicial, garantindo que seu aplicativo da Web seja de forma confiável, mesmo em uma rede lenta ou não confiável.
Se você preferir não habilitar os trabalhadores do serviço antes da implantação inicial da produção, remova a chamada para o registerServiceWorker()
do src/index.js
.
Se você tivesse ativado anteriormente os trabalhadores de serviço em sua implantação de produção e decidiu que gostaria de desativá -los por todos os seus usuários existentes, você pode trocar a chamada para registerServiceWorker()
em src/index.js
primeiro modificando a importação do trabalhador de serviço :
import { unregister } from './registerServiceWorker' ;
e depois ligue para unregister()
. Depois que o usuário visita uma página que possui unregister()
, o trabalhador do serviço será desinstalado. Observe que, dependendo de como /service-worker.js
é servido, pode levar até 24 horas para que o cache seja invalidado.
Os trabalhadores do serviço exigem HTTPs, embora para facilitar os testes locais, essa política não se aplique ao localhost
. Se o seu servidor da Web de produção não suportar HTTPS, o registro do trabalhador do serviço falhará, mas o restante do seu aplicativo da web permanecerá funcional.
Os trabalhadores de serviços não são atualmente suportados em todos os navegadores da Web. O registro do trabalhador do serviço não será tentado nos navegadores que não têm apoio.
O trabalhador do serviço está ativado apenas no ambiente de produção, por exemplo, a saída da npm run build
. É recomendável que você não permita um trabalhador de serviço offline em um ambiente de desenvolvimento, pois pode levar à frustração quando os ativos em cache anterior são usados e não incluem as últimas alterações que você fez localmente.
Se você precisar testar o seu funcionário de serviço offline localmente, crie o aplicativo (usando npm run build
) e execute um servidor HTTP simples no seu diretório de construção. Após a execução do script de compilação, create-react-app
fornecerá instruções para uma maneira de testar sua produção de construção localmente e as instruções de implantação têm instruções para usar outros métodos. Certifique -se de sempre usar uma janela incógnita para evitar complicações com o cache do navegador.
Se possível, configure seu ambiente de produção para atender ao service-worker.js
com o cache HTTP desativado. Se isso não for possível-as páginas do Github, por exemplo, não permitem alterar a vida útil do cache HTTP de 10 minutos-, então saiba que se você visitar seu local de produção e depois revisitar novamente antes service-worker.js
expirou do seu seu Cache HTTP, você continuará obtendo os ativos em cache anteriormente do trabalhador do serviço. Se você tiver uma necessidade imediata de visualizar sua implantação atualizada de produção, a execução de uma refrescamento de turno desativará temporariamente o trabalhador do serviço e recuperará todos os ativos da rede.
Os usuários nem sempre estão familiarizados com os aplicativos da Web offline. Pode ser útil que o usuário saiba quando o funcionário do serviço terminar de preencher seus caches (mostrando uma mensagem "Este aplicativo da web funciona offline!" E também informe -os quando o trabalhador do serviço tiver buscado as atualizações mais recentes que estarão disponíveis, o Da próxima vez que carregarem a página (mostrando um "novo conteúdo está disponível; por favor, atualize". "Mensagem). Atualmente, mostrando que as mensagens são deixadas como um exercício para o desenvolvedor, mas como ponto de partida, você pode usar a lógica incluída no src/registerServiceWorker.js
, que demonstra quais eventos do ciclo de vida do trabalhador do serviço ouvir para detectar cada cenário e e que, como padrão, apenas registra mensagens apropriadas para o console JavaScript.
Por padrão, o arquivo de trabalhador de serviço gerado não interceptará ou cache nenhum tráfego de origem cruzada, como solicitações, imagens ou incorporação da API HTTP carregadas de um domínio diferente. Se você deseja usar uma estratégia de cache de tempo de execução para essas solicitações, poderá eject
e configurar a opção runtimeCaching
na seção SWPrecacheWebpackPlugin
do webpack.config.prod.js
.
A configuração padrão inclui um manifesto de aplicativo da web localizado em public/manifest.json
, que você pode personalizar com detalhes específicos para o seu aplicativo da web.
Quando um usuário adiciona um aplicativo da Web à tela inicial usando Chrome ou Firefox no Android, os metadados no manifest.json
determina quais ícones, nomes e cores de marca a serem usados quando o aplicativo da web é exibido. O guia de manifestos do aplicativo da web fornece mais contexto sobre o que cada campo significa e como suas personalizações afetarão a experiência de seus usuários.
O MAPO DE ORIGE MAPLIONE Analisa os pacotes JavaScript usando os mapas de origem. Isso ajuda você a entender de onde vem o código Bloat.
Para adicionar o MAPO de origem Explorer a um projeto Create React App, siga estas etapas:
npm install --save source-map-explorer
Como alternativa, você pode usar yarn
:
yarn add source-map-explorer
Em seguida, no package.json
, adicione a seguinte linha aos scripts
:
"scripts": {
+ "analyze": "source-map-explorer build/static/js/main.*",
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test --env=jsdom",
Em seguida, para analisar o pacote, execute a construção da produção e execute o script de análise.
npm run build
npm run analyze
npm run build
cria um diretório build
com uma construção de produção do seu aplicativo. Configure seu servidor HTTP favorito para que um visitante do seu site seja servido index.html
, e solicitações para caminhos estáticos como /static/js/main.<hash>.js
são servidos com o conteúdo do /static/js/main.<hash>.js
arquivo.
Para ambientes usando o nó, a maneira mais fácil de lidar com isso seria instalar o saque e deixá -lo lidar com o resto:
npm install -g serve
serve -s build
O último comando mostrado acima servirá ao seu site estático na porta 5000 . Como muitas das configurações internas do Serv, a porta pode ser ajustada usando os sinalizadores -p
ou --port
.
Execute este comando para obter uma lista completa das opções disponíveis:
serve -h
Você não precisa necessariamente de um servidor estático para executar um projeto de aplicativo Create React em produção. Funciona tão bem integrado a um dinâmico existente.
Aqui está um exemplo programático usando o nó e expresso:
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 ) ;
A escolha do seu software de servidor também não é importante. Como o aplicativo Create React é completamente agnóstico da plataforma, não há necessidade de usar explicitamente o nó.
A pasta build
com ativos estáticos é a única saída produzida pelo aplicativo Create React.
No entanto, isso não é suficiente se você usar o roteamento do lado do cliente. 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.
Por exemplo:
< 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.
Variável | Desenvolvimento | Produção | Uso |
---|---|---|---|
NAVEGADOR | ✅ | By default, Create React App will open the default system browser, favoring Chrome on macOS. Specify a browser to override this behavior, or set it to none to disable it completely. If you need to customize the way the browser is launched, you can specify a node script instead. Any arguments passed to npm start will also be passed to this script, and the url where your app is served will be the last argument. Your script's file name must have the .js extension. | |
HOSPEDAR | ✅ | By default, the development web server binds to localhost . You may use this variable to specify a different host. | |
PORTA | ✅ | 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. | |
IC | ? | ✅ | When set to true , Create React App treats warnings as failures in the build. It also makes the test runner non-watching. Most CIs set this flag by default. |
REACT_EDITOR | ✅ | When an app crashes in development, you will see an error overlay with clickable stack trace. When you click on it, Create React App will try to determine the editor you are using based on currently running processes, and open the relevant source file. You can send a pull request to detect your editor of choice. Setting this environment variable overrides the automatic detection. If you do it, make sure your systems PATH environment variable points to your editor's bin folder. You can also set it to none to disable it completely. | |
CHOKIDAR_USEPOLLING | ✅ | When set to true , the watcher runs in polling mode, as necessary inside a VM. Use this option if npm start isn't detecting changes. | |
GENERATE_SOURCEMAP | ✅ | When set to false , source maps are not generated for a production build. This solves OOM issues on some smaller machines. | |
NODE_PATH | ✅ | ✅ | Same as NODE_PATH in Node.js, but only relative folders are allowed. Can be handy for emulating a monorepo setup by setting NODE_PATH=src . |
npm start
doesn't detect changes When you save a file while npm start
is running, the browser should refresh with the updated code.
If this doesn't happen, try one of the following workarounds:
index.js
and you're referencing it by the folder name, you need to restart the watcher due to a Webpack bug..env
file in your project directory if it doesn't exist, and add CHOKIDAR_USEPOLLING=true
to it. This ensures that the next time you run npm start
, the watcher uses the polling mode, as necessary inside a VM.If none of these solutions help please leave a comment in this thread.
npm test
hangs on macOS Sierra If you run npm test
and the console gets stuck after printing react-scripts test --env=jsdom
to the console there might be a problem with your Watchman installation as described in facebookincubator/create-react-app#713.
We recommend deleting node_modules
in your project and running npm install
(or yarn
if you use it) first. If it doesn't help, you can try one of the numerous workarounds mentioned in these issues:
It is reported that installing Watchman 4.7.0 or newer fixes the issue. If you use Homebrew, you can run these commands to update it:
watchman shutdown-server
brew update
brew reinstall watchman
You can find other installation methods on the Watchman documentation page.
If this still doesn't help, try running launchctl unload -F ~/Library/LaunchAgents/com.github.facebook.watchman.plist
.
There are also reports that uninstalling Watchman fixes the issue. So if nothing else helps, remove it from your system and try again.
npm run build
exits too early It is reported that npm run build
can fail on machines with limited memory and no swap space, which is common in cloud environments. Even with small projects this command can increase RAM usage in your system by hundreds of megabytes, so if you have less than 1 GB of available memory your build is likely to fail with the following message:
The build failed because the process exited too early. This probably means the system ran out of memory or someone called
kill -9
on the process.
If you are completely sure that you didn't terminate the process, consider adding some swap space to the machine you're building on, or build the project locally.
npm run build
fails on HerokuThis may be a problem with case sensitive filenames. Please refer to this section.
If you use a Moment.js, you might notice that only the English locale is available by default. This is because the locale files are large, and you probably only need a subset of all the locales provided by Moment.js.
To add a specific Moment.js locale to your bundle, you need to import it explicitly.
Por exemplo:
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!