Sem novos recursos

A versão React 17 é incomum porque não adiciona nenhum novo recurso voltado para o desenvolvedor. Em vez disso, este lançamento está focado principalmente em tornar mais fácil atualizar o próprio React.

Em particular, o React 17 é uma versão de “trampolim” que torna mais seguro incorporar uma árvore gerenciada por uma versão do React dentro de uma árvore gerenciada por uma versão diferente do React.

Também torna mais fácil incorporar o React a aplicativos desenvolvidos com outras tecnologias.

Upgrades Graduais

O React 17 permite atualizações graduais do React. Quando você atualiza do React 15 para o 16 (ou, desta vez, do React 16 para o 17), normalmente atualiza o aplicativo inteiro de uma vez. Isso funciona bem para muitos aplicativos. Mas pode se tornar cada vez mais desafiador se a base de código foi escrita há alguns anos e não é mantida ativamente. E embora seja possível usar duas versões do React na página, até o React 17 isso era frágil e causava problemas com eventos.

Estamos corrigindo muitos desses problemas com o React 17. Isso significa que quando React 18 e as próximas versões futuras forem lançadas, você terá mais opções. A primeira opção será atualizar todo o seu aplicativo de uma vez, como você pode ter feito antes. Mas você também terá a opção de atualizar seu aplicativo peça por peça. Por exemplo, você pode decidir migrar a maior parte do seu aplicativo para o React 18, mas manter algumas caixas de diálogo carregadas lentamente ou um sub-rota no React 17.

Isso não significa você precise fazer atualizações graduais. Para a maioria dos aplicativos, atualizar tudo de uma vez ainda é a melhor solução. Carregar duas versões do React - mesmo se uma delas for carregada lentamente sob demanda - ainda não é o ideal. No entanto, para aplicativos maiores que não são mantidos ativamente, faz sentido considerar essa opção, e o React 17 permite que esses aplicativos não sejam deixados para trás.

Nós preparamos um repositório de exemplo demonstrando como carregar lentamente uma versão anterior do React, se necessário. Esta demonstração usa Create React App, mas deve ser possível seguir uma abordagem semelhante com qualquer outra ferramenta. Aceitamos demonstrações usando outras ferramentas como pull requests.

Nota

Adiamos outras mudanças até depois do React 17. O objetivo desta versão é permitir atualizações graduais. Se atualizar para React 17 fosse muito difícil, isso iria contra o seu propósito.

Mudanças na Delegação do Evento

Para permitir atualizações graduais, precisamos fazer algumas mudanças no sistema de eventos React. O React 17 é um grande lançamento porque essas alterações são potencialmente prejudiciais. Você pode conferir nosso FAQ de versionamento para saber mais sobre nosso compromisso com a estabilidade.

No React 17, o React não anexará mais manipuladores de eventos no nível do documento sob o hood. Em vez disso, ele os anexará ao contêiner root DOM no qual sua árvore React é renderizada:

const rootNode = document.getElementById('root');
ReactDOM.render(<App />, rootNode);

No React 16 e anteriores, o React faria document.addEventListener() para a maioria dos eventos. React 17 ligará rootNode.addEventListener() sob o hood em vez disso.

Nós confirmamos que numerosos problemas relatados sobre os anos na nossa issue rastreador relacionadas à integração do React com o código não React foram corrigidas pelo novo comportamento.

Se você tiver problemas com essa mudança, aqui está uma maneira comum de resolvê-los.

Outras Mudanças Importantes

O post do blog React 17 RC descreve o resto das mudanças significativas no React 17.

Só tivemos que mudar menos de vinte componentes de mais de 100.000 no código de produto do Facebook para trabalhar com essas mudanças, então esperamos que a maioria dos aplicativos possa atualizar para React 17 sem muitos problemas. Por favor nos conte se você tiver problemas.

Nova transformação JSX

React 17 apoia a nova transformação JSX. Também fizemos backport para ele para React 16.14.0, React 15.7.0 e 0.14.10. Observe que é totalmente opcional e você não precisa usá-lo. A transformação JSX clássica continuará funcionando e não há planos de deixar de suportá-la.

React Native

O React Native tem uma programação de lançamento separada. Atualmente esperamos que o suporte para React 17 chegue no React Native 0.65, mas a versão exata está sujeita a alterações. Como sempre, você pode acompanhar as discussões de lançamento nos lançamentos da React Native Community rastreador de issues.

Instalação

Para instalar React 17 com npm, rode:

npm install react@17.0.0 react-dom@17.0.0

Para instalar React 17 com Yarn, rode:

yarn add react@17.0.0 react-dom@17.0.0

Também fornecemos compilações UMD do React por meio de um CDN:

<script crossorigin src="https://unpkg.com/react@17.0.0/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@17.0.0/umd/react-dom.production.min.js"></script>

Consulte a documentação para instruções de instalação detalhadas.

Changelog

React

• Adiciona react/jsx-runtime e react/jsx-dev-runtime para o new JSX transform. (@lunaruan em #18299)
• Crie pilhas de componentes a partir de frames de erro nativos. (@sebmarkbage em #18561)
• Permite especificar displayName no contexto para pilhas aprimoradas. (@eps1lon em #18224)
• Evita 'use strict' de vazamento nos pacotes UMD. (@koba04 em #19614)
• Para de usar fb.me para redirecionamentos. (@cylim em #19598)

React DOM

• Delega eventos aos roots em vez de document. (@trueadm em #18195 e others)
• Limpa todos os efeitos antes de executar os próximos efeitos. (@bvaughn em #17947)
• Roda useEffect limpando funções assíncronas. (@bvaughn em #17925)
• Usa o navegador focusin e focusout para onFocus e onBlur. (@trueadm em #19186)
• Faz com que eventos Capture usem a fase de captura do navegador. (@trueadm em #19221)
• Não imita o borbulhar do evento onScroll. (@gaearon em #19464)
• Lança se o componente forwardRef oumemo retornar ʻundefined`. (@gaearon em #19550)
• Remove o pool de eventos. (@trueadm em #18969)
• Para de expor detalhes internos que não serão necessários para o React Native Web. (@necolas em #18483)
• Anexa todos os ouvintes de eventos conhecidos quando o hoot for montado. (@gaearon em #19659)
• Desabilita console na segunda passagem de renderização do modo DEV, renderização dupla. (@sebmarkbage em #18547)
• Rejeita o não documentado e enganoso API do ReactTestUtils.SimulateNative. (@gaearon em #13407)
• Renomeia os nomes dos campos privados usados ​​nos internos. (@gaearon em #18377)
• Não chama a API User Timing no desenvolvimento. (@gaearon em #18417)
• Desabilita o console durante a renderização repetida no modo estrito. (@sebmarkbage em #18547)
• No Modo Estrito, os componentes de renderização dupla sem Hooks. (@eps1lon em #18430)
• Permite chamadas ReactDOM.flushSync durante os métodos de ciclo de vida (com aviso). (@sebmarkbage em #18759)
• Adiciona a propriedade code aos objetos de evento do teclado. (@bl00mber em #18287)
• Adiciona a propriedade disableRemotePlayback para elementos video. (@tombrowndev em #18619)
• Adiciona a propriedade enterKeyHint para elementos input. (@eps1lon em #18634)
• Avisa quando value não é fornecido para <Context.Provider>. (@charlie1404 em #19054)
• Avisa quando o componentememo ou forwardRef retorna undefined. (@bvaughn em #19550)
• Melhora a mensagem de erro para atualizações inválidas. (@JoviDeCroock em #18316)
• Exclui forwardRef e memo dos frames da pilha. (@sebmarkbage em #18559)
• Melhora a mensagem de erro ao alternar entre entradas controladas e não controladas. (@vcarl em #17070)
• Mantém onTouchStart, onTouchMove, e onWheel passivo. (@gaearon em #19654)
• Conserta setState em desenvolvimento dentro de um iframe fechado. (@gaearon em #19220)
• Corrige resgate de renderização para componentes lentos com defaultProps. (@jddxf em #18539)
• Corrige um aviso de falso positivo quando dangerouslySetInnerHTML é undefined. (@eps1lon em #18676)
• Corrige utilitários de teste fora do padrão de implementação require. (@just-boris em #18632)
• Corrige onBeforeInput relatando um incorreto event.type. (@eps1lon em #19561)
• Corrige event.relatedTarget relatado como undefined em Firefox. (@claytercek em #19607)
• Corrige “erro não especificado” em IE11. (@hemakshis em #19664)
• Corrige a renderização em uma sombra root. (@Jack-Works em #15894)
• Corrige movementX/Y polyfill com eventos de captura. (@gaearon em #19672)
• Usa delegação para onSubmit e onReset eventos. (@gaearon em #19333)
• Melhora o uso de memória. (@trueadm em #18970)

React DOM Server

• Torne o comportamento do useCallback consistente com ʻuseMemo` para o renderizador do servidor.(@alexmckenley em #18783)
• Corrige o vazamento de estado quando um componente de função é acionado. (@pmaccart em #19212)

React Test Renderer

• Melhora findByType mensagem de erro. (@henryqdineen em #17439)

Modo Simultâneo (Experimental)

• Renova as heurísticas de lote de prioridade. (@acdlite em #18796)
• Adiciona o prefixo unstable_ antes do experimental APIs. (@acdlite em #18825)
• Remove unstable_discreteUpdates e unstable_flushDiscreteUpdates. (@trueadm em #18825)
• Remove o argumento timeoutMs. (@acdlite em #19703)
• Desabilita pré-renderização <div hidden /> em favor de uma futura API diferente. (@acdlite em #18917)
• Adiciona unstable_expectedLoadTime ao Suspense para árvores vinculadas à CPU. (@acdlite in #19936)
• Adiciona um Hook experimental unstable_useOpaqueIdentifier. (@lunaruan em #17322)
• Adiciona uma API experimental unstable_startTransition. (@rickhanlonii em #19696)
• Usando act no renderizador de teste não libera mais fallbacks do Suspense. (@acdlite em #18596)
• Usa o tempo limite de renderização global para CPU Suspense. (@sebmarkbage em #19643)
• Limpa o conteúdo hoot existente antes da montagem. (@bvaughn em #18730)
• Corrige um bug com limites de erro. (@acdlite em #18265)
• Corrige um bug que causava atualizações perdidas em uma árvore suspensa. (@acdlite em #18384 e #18457)
• Corrige um bug que causava atualizações da fase de renderização perdidas (@acdlite em #18537)
• Corrige um bug em SuspenseList. (@sebmarkbage em #18412)
• Corrige um bug que fazia com que o substituto do Suspense fosse exibido muito cedo. (@acdlite em #18411)
• Corrige um bug com componentes de classe dentro de SuspenseList. (@sebmarkbage em #18448)
• Corrige um bug com inputs que pode fazer com que as atualizações sejam descartadas. (@jddxf em #18515 e @acdlite em #18535)
• Corrige um bug que fazia com que o recurso de suspensão do Suspense travasse. (@acdlite em #18663)
• Não corta a tail de uma SuspenseList se carregando informações. (@sebmarkbage em #18854)
• Conserta um bug em useMutableSource isso pode acontecer quando alteraçõesgetSnapshot. (@bvaughn em #18297)
• Corrige um sério bug em useMutableSource. (@bvaughn em #18912)
• Avisa se chamando setState fora da renderização, mas antes do commit. (@sebmarkbage em #18838)

O Que é um JSX Transform?

Os navegadores não entendem JSX imediatamente, então a maioria dos usuários do React confia em um compilador como o Babel ou TypeScript para transformar o código JSX em JavaScript regular. Muitos toolkits pré-configurados como o Create React App ou Next.js também incluem um JSX Transform por baixo do capô.

Junto com a versão React 17, queríamos fazer algumas melhorias no JSX Transform, mas não queríamos quebrar as configurações existentes. É por isso que trabalhamos com Babel para oferecer uma versão nova e reescrita do JSX Transform para pessoas que gostariam de atualizar.

Atualizar para a nova transformação é totalmente opcional, mas tem alguns benefícios:

• Com a nova transformação, você pode usar JSX sem importar o React.
• Dependendo de sua configuração, a saída compilada pode melhorar ligeiramente o tamanho do pacote.
• Isso permitirá melhorias futuras que reduzem o número de conceitos que você precisa para aprender React.

Esta atualização não mudará a sintaxe JSX e não é necessária. O antigo JSX Transform continuará funcionando normalmente e não há planos de remover o suporte para ele.

React 17 RC já inclui suporte para a nova transformação, então experimente! Para facilitar a adoção também adaptamos seu suporte para React 16.14.0, React 15.7.0 e React 0.14.10. Você pode encontrar as instruções de atualização para diferentes ferramentas abaixo.

Agora, vamos examinar mais de perto as diferenças entre a velha e a nova transformação.

O Que Há de Diferente na Nova Transformação?

Quando você usa JSX, o compilador o transforma em chamadas de função React que o navegador pode entender. A antiga transformação JSX transforma JSX em chamadas React.createElement(...).

Por exemplo, digamos que seu código-fonte tenha a seguinte aparência:

import React from 'react';

function App() {
  return <h1>Hello World</h1>;
}

Nos bastidores, a antiga transformação JSX o transforma em JavaScript regular:

import React from 'react';

function App() {
  return React.createElement('h1', null, 'Hello world');
}

Nota

Seu código-font não precisa ser alterado de forma alguma. Estamos descrevendo como a transformação JSX transforma seu código-fonte JSX no código JavaScript que um navegador pode entender.

No entanto, isso não é perfeito:

• Como JSX foi compilado em React.createElement, React precisa estar no escopo se você usasse JSX.
• Existe algumas melhorias e simplificações de desempenho que React.createElement não permite.

Para resolver esses problemas, o React 17 apresenta dois novos pontos de entrada para o pacote React que devem ser usados apenas por compiladores como Babel e TypeScript. Em vez de transformar JSX em React.createElement, a nova transformação JSX importa automaticamente funções especiais desses novos pontos de entrada no pacote React e os chama.

Digamos que seu código-fonte tenha a seguinte aparência:

function App() {
  return <h1>Hello World</h1>;
}

É para isso que a nova transformação JSX o compila:

// Inserido por um compilador (não importe você mesmo!)
import {jsx as _jsx} from 'react/jsx-runtime';

function App() {
  return _jsx('h1', { children: 'Hello world' });
}

Observe como nosso código original não precisava mais importar o React para usar JSX! (Mas ainda precisaríamos importar o React para usar Hooks ou outras exportações que o React fornece.)

Esta mudança é totalmente compatível com todo o código JSX existente, assim você não terá que mudar seus componentes. Se estiver curioso, vocÊ pode verificar a RFC técnica para obter mais detalhes sobre como a nova transformação funciona.

Nota

As funções dentro de react/jsx-runtime e react/jsx-dev-runtime devem ser usadas apenas pela transformação do compilador. Se você precisa criar elementos manualmente em seu código, você deve continuar usando React.createElement. Ele continuará a funcionar e não irá embora.

Como Fazer Upgrade para a Nova Transformação JSX

Se você não estiver pronto para atualizar para a nova transformação JSX ou se estiver usando JSX para outra biblioteca, não se preocupe. A transformação antiga não será removida e continuará a ter suporte.

Se quiser fazer upgrade, você precisará de duas coisas:

• Uma versão do React que suporta a nova transformação (React 17 RC e superior suportam, mas também lançamos React 16.14.0, React 15.7.0 e React 0.14.10 para pessoas que ainda estão nas versões principais mais antigas).
• Um compilador compatível (consulte as instruções para diferentes ferramentas abaixo).

Como a nova transformação JSX não exige que o React esteja no escopo, também preparamos um script automatizado que removerá as importações desnecessárias de sua base de código.

Create React App

Create React App 4.0.0+ usa a nova transformação para versões compatíveis do React.

Next.js

Next.js v9.5.3+ usa a nova transformação para versões compatíveis do React.

Gatsby

Gatsby v2.24.5+ usa a nova transformação para versões compatíveis do React.

Nota

Se você obtiver este erro de Gatsby após atualizar para React 17 RC, execute npm update para corrigi-lo.

Configuração Manual do Babel

O suporte para a nova transformação JSX está disponível no Babel v7.9.0 e superior.

Primeiro, você precisará atualizar para a última transformação do Babel e do plugin.

Se você estiver usando @babel/plugin-transform-react-jsx:

# para usuários npm
npm update @babel/core @babel/plugin-transform-react-jsx

# para usuários yarn
yarn upgrade @babel/core @babel/plugin-transform-react-jsx

Se você estiver usando @babel/preset-react:

# para usuários npm
npm update @babel/core @babel/preset-react

# para usuários yarn
yarn upgrade @babel/core @babel/preset-react

Atualmente, a antiga transformação {"runtime": "classic"} é a opção padrão. Para habilitar a nova transformação, você pode passar {"runtime": "automatic"} como uma opção para @babel/plugin-transform-react-jsx ou @babel/preset-react:

// Se você estiver usando @babel/preset-react
{
  "presets": [
    ["@babel/preset-react", {
      "runtime": "automatic"
    }]
  ]
}

// Se você estiver usando @babel/plugin-transform-react-jsx
{
  "plugins": [
    ["@babel/plugin-transform-react-jsx", {
      "runtime": "automatic"
    }]
  ]
}

A partir do Babel 8, "automatic" será o tempo de execução padrão para ambos os plug-ins. Para obter mais informações, verifique a documentação do Babel para @babel/plugin-transform-react-jsx e @babel/preset-react.

Nota

Se você usar JSX com uma biblioteca diferente de React, você pode usar a opção importSource para importar dessa biblioteca - desde que forneça os pontos de entrada necessários. Como alternativa, você pode continuar usando a transformação clássica, que continuará a ser compatível.

Se você é um autor de biblioteca e está implementando o ponto de entrada /jsx-runtime para sua biblioteca, tenha em mente que há um caso em que até mesmo a nova transformação tem que voltar para createElement para compatibilidade de versões anteriores. Nesse caso, ele irá importar automaticamente createElement diretamente do ponto de entrada root especificado por importSource.

ESLint

Se você estiver usando eslint-plugin-react, as regas de react/jsx-uses-react e react/react-in-jsx-scope não são mais necessárias e podem ser desativadas ou removidas.

{
  // ...
  "rules": {
    // ...
    "react/jsx-uses-react": "off",
    "react/react-in-jsx-scope": "off"
  }
}

TypeScript

TypeScript suporta a nova transformação JSX em v4.1.

Flow

Flow suporta a nova transformação JSX em v0.126.0 para cima, adicionando react.runtime = automatic às opções de configuração do Flow.

Removendo Imports React não Utilizadas

Como a nova transformação JSX importará automaticamente as funções react/jsx-runtime necessárias, o React não precisará mais estar no escopo quando você usar JSX. Isso pode levar a importação React não utilizadas em seu código. Não faz mal mantê-los, mas se quiser removê-los, recomendamos a execução de um script “codemod” para removê-los automaticamente:

cd your_project
npx react-codemod update-react-imports

Nota

Se você estiver recebendo errors ao executar o codemod, tente especificar um dialeto JavaScript diferente quando npx react-codemod update-react-imports solicitar que você escolha um. Em particular, neste momento, a configuração “JavaScript com Flow” suporta sintaxe mais recente do que a configuração “JavaScript”, mesmo se você não usar o Flow. Crie uma issue se você tiver problemas.

Lembre-se de que a saída do codemod nem sempre corresponderá ao estilo de codificação do seu projeto, então você pode querer executar Prettier depois que o codemod terminar para uma formatação consistente.

Executar este codemod irá:

• Remover todas as importações React não utilizadas como resultado da atualização para a nova transformação JSX.
• Alterar todas as importações React padrão (ou seja, import React from "react") para importações nomeadas desestruturadas (ex. import { useState } from "react"), que é o estilo preferido no futuro. Este codemod não afetará as importações de namespace existentes (ou seja, import * as React from "react"), que também é um estilo válido. As importações padrão continuarão funcionando no React 17, mas, a longo prazo, encorajamos nos afastar delas.

Por exemplo,

import React from 'react';

function App() {
  return <h1>Olá Mundo</h1>;
}

será substituído por

function App() {
  return <h1>Olá Mundo</h1>;
}

Se você usar alguma outra importação do React - por exemplo, um Hook - então o codemod irá convertê-lo em uma importação nomeada.

Por exemplo,

import React from 'react';

function App() {
  const [text, setText] = React.useState('Olá Mundo');
  return <h1>{text}</h1>;
}

será substituído por

import { useState } from 'react';

function App() {
  const [text, setText] = useState('Olá Mundo');
  return <h1>{text}</h1>;
}

Além de limpar as importações não utilizadas, isso também o ajudará a se preparar para uma versão principal futura do React (não do React 17), que oferecerá suporte aos Módulos ES e não terá uma exportação padrão.

Obrigado

Gostaríamso de agradecer aos mantenedores de Babel, TypeScript, Create React App, Next.js, Gatsby, ESLint e Flow por sua ajuda na implementação e intergação da nova transformação JSX. Também queremos agradecer à comunidade React por seus comentários e discussões sobre a RFC técnica.

Sem novas funcionalidades

A versão React 17 é incomum porque não adiciona nenhum novo recurso voltado para o desenvolvedor. Em vez disso, esta versão está focada principalmente em tornar mais fácil atualizar o próprio React.

Estamos trabalhando ativamente nos novos recursos do React, mas eles não fazem parte desta versão. O lançamento do React 17 é uma parte fundamental de nossa estratégia para implementá-los sem deixar ninguém para trás.

Em particular, o React 17 é uma versão “passo a passo” que torna mais seguro incorporar uma árvore gerenciada por uma versão do React dentro de uma árvore gerenciada por uma versão diferente do React.

Atualizações Graduais

Nos últimos sete anos, as atualizações do React têm sido “tudo ou nada”. Ou você permanece com uma versão antiga ou atualiza todo o seu aplicativo para uma nova versão. Não havia meio-termo.

Isso funcionou até agora, mas estamos atingindo os limites da estratégia de atualização “tudo ou nada”. Algumas mudanças de API, por exemplo, descontinuar a legada API de contexto, são impossíveis de fazer de forma automatizada. Mesmo que a maioria dos aplicativos escritos hoje nunca os use, ainda oferecemos suporte para eles no React. Temos que escolher entre suportá-los no React indefinidamente ou deixar alguns aplicativos para trás em uma versão antiga do React. Ambas as opções não são boas.

Portanto, queríamos oferecer outra opção.

React 17 permite atualizações graduais do React. Quando você atualiza do React 15 para o 16 (ou, em breve, do React 16 para o 17), normalmente atualiza todo o seu aplicativo de uma vez. Isso funciona bem para muitos aplicativos. Mas pode ser cada vez mais desafiador se a base de código foi escrita há mais de alguns anos e não é mantida ativamente. E embora seja possível usar duas versões do React na mesma página, até o React 17 isso era frágil e causava problemas com eventos.

Estamos corrigindo muitos desses problemas com o React 17. Isso significa que quando o React 18 e as próximas versões futuras forem lançadas, você terá mais opções. A primeira opção será atualizar todo o seu aplicativo de uma vez, como você pode ter feito antes. Mas você também terá a opção de atualizar seu aplicativo peça por peça. Por exemplo, você pode decidir migrar a maior parte do seu aplicativo para o React 18, mas manter algumas caixas de diálogo lazy-loaded ou um sub-rota no React 17.

Isso não significa que você precise fazer atualizações graduais. Para a maioria dos aplicativos, atualizar tudo de uma vez ainda é a melhor solução. Carregar duas versões do React — mesmo se uma delas for carregada lentamente sob demanda — ainda não é o ideal. No entanto, para aplicativos maiores que não são mantidos ativamente, pode fazer sentido considerar essa opção, e o React 17 permite que esses aplicativos não sejam deixados para trás.

Para permitir atualizações graduais, precisamos fazer algumas mudanças no sistema de eventos do React. O React 17 é um grande lançamento porque essas alterações são potencialmente prejudiciais. Na prática, só tivemos que mudar menos de vinte componentes de mais de 100.000, então esperamos que a maioria dos aplicativos possa atualizar para o React 17 sem muitos problemas. Conte-nos se você tiver problemas.

Demonstração das atualizações graduais

Preparamos um repositório de exemplo demonstrando como carregar lentamente uma versão mais antiga do React, se necessário. Esta demonstração usa Create React App, mas deve ser possível seguir uma abordagem semelhante com qualquer outra ferramenta. Aceitamos pull requests com demonstrações usando outras ferramentas.

Nota

Adiamos outras mudanças até depois do React 17. O objetivo desta versão é permitir atualizações graduais. Se atualizar para React 17 fosse muito difícil, isso iria contra o seu propósito.

Alterações na delegação de eventos

Tecnicamente, sempre foi possível aninhar aplicativos desenvolvidos com diferentes versões do React. No entanto, era bastante frágil por causa de como o sistema de eventos React funcionava.

Nos componentes React, você geralmente escreve manipuladores de eventos (event handler) inline:

<button onClick={handleClick}>

O DOM vanilla equivalente a este código é semelhante à:

myButton.addEventListener('click', handleClick);

No entanto, para a maioria dos eventos, o React não os anexa aos nós DOM nos quais você os declara. Em vez disso, o React anexa um manipulador por tipo de evento diretamente no nó document. Isso é chamado de delegação de evento. Além de seus benefícios de desempenho em grandes árvores de aplicativos, também torna mais fácil adicionar novos recursos como eventos de repetição.

O React faz a delegação de eventos automaticamente desde seu primeiro lançamento. Quando um evento DOM é disparado no documento, o React descobre qual componente deve ser chamado e, em seguida, o evento React “propaga” para cima através de seus componentes. Mas, nos bastidores, o evento nativo já atingiu o nível documento, onde o React instala seus manipuladores de eventos.

No entanto, esse é um problema para atualizações graduais.

Se você tiver várias versões do React na página, todas elas registram manipulador de eventos (event handler) na parte superior. Isso quebra e.stopPropagation(): se uma árvore aninhada parou a propagação de um evento, a árvore externa ainda o receberia. Isso tornou difícil aninhar diferentes versões do React. Essa preocupação não é hipotética — por exemplo, o editor Atom encontrou isso quatro anos atrás.

É por isso que estamos mudando a forma como o React anexa eventos ao DOM nos bastidores.

No React 17, o React não anexará mais manipuladores de eventos no nível do documento. Em vez disso, ele os anexará ao contêiner DOM raiz no qual sua árvore do React é renderizada:

const rootNode = document.getElementById('root');
ReactDOM.render(<App />, rootNode);

No React 16 e anteriores, o React faria document.addEventListener() para a maioria dos eventos. O React 17 chamará rootNode.addEventListener() por debaixo dos panos.

Graças a essa mudança, agora é mais seguro incorporar uma árvore do React gerenciada por uma versão dentro de uma árvore gerenciada por uma versão diferente do React. Observe que para que isso funcione, ambas as versões precisam ser 17 ou superior, por isso atualizar para React 17 é importante. De certa forma, o React 17 é um lançamento “trampolim” que torna as próximas atualizações graduais viáveis.

Essa mudança também torna mais fácil incorporar o React em aplicativos desenvolvidos com outras tecnologias. Por exemplo, se o “shell” externo de seu aplicativo for escrito em jQuery, mas o código mais recente dentro dele for escrito com React, e.stopPropagation() dentro do código React agora evitará que ele alcance o código jQuery — como você esperaria. Isso também funciona na outra direção. Se você não gosta mais de React e deseja reescrever seu aplicativo — por exemplo, em jQuery — você pode começar a converter o shell externo de React para jQuery sem interromper a propagação do evento.

Confirmamos que vários problemas relatados ao longo dos anos em nosso rastreador de problemas relacionadas à integração do React com o código não React foram corrigidas pelo novo comportamento.

Nota

Você deve estar se perguntando se isso quebra o Portals fora do contêiner raiz. A resposta é que o React também ouve eventos nos contêineres do portal, portanto, isso não é um problema.

Corrigindo potenciais problemas

Como acontece com qualquer alteração importante, é provável que algum código precise ser ajustado. No Facebook, tivemos que ajustar cerca de 10 módulos no total (de muitos milhares) para trabalhar com essa mudança.

Por exemplo, se você adicionar manualmente os DOM listners com document.addEventListener(...), você pode esperar que eles capturem todos os eventos React. No React 16 e anteriores, mesmo se você chamar e.stopPropagation() em um manipulador de eventos (event handler) do React, seus listners document personalizados ainda os receberão porque o evento nativo já está no nível do documento. Com React 17, a propagação iria parar (conforme solicitado!), Então seus manipuladores de document não disparariam:

document.addEventListener('click', function() {
  // Este manipulador personalizado não receberá mais cliques
  // dos componentes React que chamaram e.stopPropagation()
});

Você pode corrigir um código como esse convertendo seu listener para usar a fase de captura. Para fazer isso, você pode passar { capture: true } como o terceiro argumento para document.addEventListener:

document.addEventListener('click', function() {
  // Agora este event handlers usa a fase de captura
  // então ele recebe *todas* os eventos de clique abaixo!
}, { capture: true });

Observe como essa estratégia é mais resiliente no geral — por exemplo, ela provavelmente corrigirá bugs existentes em seu código que acontecem quando e.stopPropagation() é chamado fora de um manipulador de eventos (event handler) React. Em outras palavras, a propagação do evento no React 17 funciona mais próxima do DOM regular .

Outras alterações significativas

Mantivemos as alterações significativas no React 17 ao mínimo. Por exemplo, ele não remove nenhum dos métodos que foram descontinuados nas versões anteriores. No entanto, inclui algumas outras alterações importantes que têm sido relativamente seguras em nossa experiência. No total, tivemos que ajustar menos de 20 de mais de 100.000 nossos componentes por causa deles.

Alinhando com navegadores

Fizemos algumas alterações menores relacionadas ao sistema de eventos:

• O evento onScroll não propaga mais a fim de previnir algumas confusões comuns.
• Os eventos React onFocus e onBlur passaram a usar os eventos nativos focusin efocusout por debaixo dos panos, que se aproximam mais do comportamento existente do React e às vezes fornecem informações extras.
• Os eventos de fase de captura (por exemplo, onClickCapture) agora usam ouvintes de fase de captura do navegador real.

Essas mudanças alinham o React mais de perto com o comportamento do navegador e melhoram a interoperabilidade.

Nota

Embora o React 17 tenha mudado de focus parafocusin por debaixo dos panos para o evento onFocus, note que isso não afetou o comportamento de propagação. No React, o evento onFocus sempre propagava e continua a ocorrer no React 17 porque geralmente é um padrão mais útil. Consulte este sandbox para as diferentes verificações que você pode adicionar para diferentes casos de uso específicos.

Sem pool de eventos

O React 17 remove a otimização de pooling de eventos do React. Ele não melhora o desempenho em navegadores modernos e confunde até mesmo usuários experientes do React:

function handleChange(e) {
  setData(data => ({
    ...data,
    // Isso trava no React 16 e anteriores:
    text: e.target.value
  }));
}

Isso ocorre porque o React reutilizou os objetos de evento entre diferentes eventos para desempenho em navegadores antigos e definiu todos os campos de evento como null entre eles. Com o React 16 e anteriores, você deve chamar e.persist() para usar o evento apropriadamente ou ler a propriedade que você precisa anteriormente.

No React 17, este código funciona conforme o esperado. A antiga otimização do pool de eventos foi totalmente removida, para que você possa ler os campos do evento sempre que precisar.

Esta é uma mudança de comportamento, e é por isso que a estamos marcando como falha, mas na prática não vimos nada quebrar no Facebook. (Talvez até tenha corrigido alguns bugs!) Observe que e.persist() ainda está disponível no objeto de evento React, mas agora não faz nada.

Tempo de limpeza do Effect

Estamos tornando o tempo da função de limpeza useEffect mais consistente.

useEffect (() => {
  // Este é o próprio Effect.
  return () => {    // Esta é sua limpeza.  };});

A maioria dos efeitos não precisa atrasar as atualizações da tela, portanto, o React os executa de forma assíncrona logo após a atualização ser refletida na tela. (Para os raros casos em que você precisa de um efeito para bloquear a pintura, por exemplo, para medir e posicionar uma tooltip, prefira useLayoutEffect.)

No entanto, quando um componente é desmontado, as funções de limpeza de efeito usadas para serem executadas de maneira síncrona (semelhante a componentWillUnmount sendo síncrono em classes). Descobrimos que isso não é ideal para aplicativos maiores porque retarda as transições de telas grandes (por exemplo, alternar entre guias).

No React 17, a função de limpeza de efeito sempre é executada de forma assíncrona — por exemplo, se o componente está desmontado, a limpeza é executada após a tela ter sido atualizada.

Isso reflete como os próprios efeitos funcionam mais de perto. Nos raros casos em que você pode querer confiar na execução síncrona, você pode alternar para useLayoutEffect.

Nota

Você deve estar se perguntando se isso significa que agora você não conseguirá corrigir avisos sobre setState em componentes não montados. Não se preocupe — o React verifica especificamente este caso e não dispara avisos de setState no curto espaço entre a desmontagem e a limpeza.Portanto, as solicitações ou intervalos de cancelamento de código quase sempre podem permanecer os mesmos.

Além disso, o React 17 sempre executará todas as funções de limpeza de efeitos (para todos os componentes) antes de executar quaisquer novos efeitos. O React 16 só garantiu essa ordem para efeitos dentro de um componente.

Problemas potenciais

Nós vimos apenas alguns componentes quebrarem com essa mudança, embora as bibliotecas reutilizáveis ​​possam precisar testá-lo mais completamente. Um exemplo de código problemático pode ser assim:

useEffect(() => {
  someRef.current.someSetupMethod();
  return () => {
    someRef.current.someCleanupMethod();
  };
});

O problema é que someRef.current é mutável, portanto, no momento em que a função de limpeza é executada, pode ter sido definido como null. A solução é capturar quaisquer valores mutáveis ​​dentro do efeito:

useEffect(() => {
  const instance = someRef.current;
  instance.someSetupMethod();
  return () => {
    instance.someCleanupMethod();
  };
});

Não esperamos que este seja um problema comum porque nossa regra de lint eslint-plugin-react-hooks /haustive-deps (certifique-se de usá-lo!) sempre alertamos sobre isso.

Erros consistentes para retornar indefinido

No React 16 e anteriores, retornar undefined sempre foi um erro:

function Button() {
  return; // Erro: nada foi retornado da renderização
}

Isso ocorre em parte porque é fácil retornar undefined involuntariamente:

function Button() {
  // Esquecemos de escrever return, então este componente retorna indefinido.
  // React mostra isso como um erro em vez de ignorá-lo.
  <button />;
}

Anteriormente, o React fazia isso apenas para componentes de classe e função, mas não verificava os valores de retorno dos componentes forwardRef e memo. Isso ocorreu devido a um erro de codificação.

No React 17, o comportamento dos componentes forwardRef e memo é consistente com funções regulares e componentes de classe. Retornar undefined deles é um erro.

let Button = forwardRef(() => {
  // Esquecemos de escrever return, então este componente retorna indefinido.
  // React 17 mostra isso como um erro em vez de ignorá-lo.
  <button />;
});

let Button = memo(() => {
  // Esquecemos de escrever return, então este componente retorna indefinido.
  // React 17 mostra isso como um erro em vez de ignorá-lo.
  <button />;
});

Para os casos em que você não deseja renderizar nada intencionalmente, retorne null.

Pilhas de componentes nativos

Quando você lança um erro no navegador, o navegador fornece um rastreamento de pilha com nomes de função JavaScript e seus locais. No entanto, as pilhas de JavaScript geralmente não são suficientes para diagnosticar um problema porque a hierarquia da árvore React pode ser tão importante. Você quer saber não apenas que um Button gerou um erro, mas onde na árvore React esse Button está.

Para resolver isso, o React 16 começou a imprimir “pilhas de componentes” quando você tinha um erro. Ainda assim, eles costumavam ser inferiores às pilhas nativas de JavaScript. Em particular, eles não podiam ser clicados no console porque o React não sabia onde a função foi declarada no código-fonte. Além disso, eles eram praticamente inúteis na produção. Ao contrário das pilhas JavaScript reduzidas regulares, que podem ser restauradas automaticamente aos nomes das funções originais com um mapa de origem, com as pilhas de componentes React você tinha que escolher entre as pilhas de produção e o tamanho do pacote.

No React 17, as pilhas de componentes são geradas usando um mecanismo diferente que as une a partir das pilhas JavaScript nativas regulares. Isso permite que você obtenha os rastreamentos de pilha do componente React totalmente simbolizados em um ambiente de produção.

A maneira como o React implementa isso é um tanto heterodoxa. Atualmente, os navegadores não fornecem uma maneira de obter o quadro de pilha de uma função (arquivo de origem e localização). Portanto, quando o React detecta um erro, ele agora reconstrói sua pilha de componentes lançando (e capturando) um erro temporário de dentro de cada um dos componentes acima, quando possível. Isso adiciona uma pequena penalidade de desempenho para travamentos, mas só acontece uma vez por tipo de componente.

Se estiver curioso, você pode ler mais detalhes neste pull request, mas na maior parte, este mecanismo exato não deve afetar seu código. De sua perspectiva, o novo recurso é que as pilhas de componentes agora são clicáveis ​​(porque contam com os frames de pilha do navegador nativo) e que você pode decodificá-los em produção como faria com erros regulares de JavaScript.

A parte que constitui uma alteração significativa é que, para que isso funcione, o React executa novamente partes de algumas das funções do React e dos construtores da classe React acima na pilha depois que um erro é capturado. Uma vez que funções de renderização e construtores de classe não devem ter efeitos colaterais (o que também é importante para a renderização de servidor), isso não deve representar nenhum problema prático.

Removendo exportações privadas

Por fim, a última mudança importante notável é que removemos alguns componentes internos do React que foram previamente expostos a outros projetos. Em particular, React Native for Web costumava depender de alguns componentes internos do sistema de eventos, mas essa dependência era frágil e costumava quebrar.

No React 17, essas exportações privadas foram removidas. Pelo que sabemos, React Native for Web foi o único projeto que os utilizou, e eles já concluíram uma migração para uma abordagem diferente que não depende dessas exportações privadas.

Isso significa que as versões anteriores do React Native for Web não serão compatíveis com o React 17, mas as versões mais recentes funcionarão com ele. Na prática, isso não muda muito porque o React Native for Web teve que lançar novas versões para se adaptar às mudanças internas do React.

Além disso, removemos os métodos auxiliares ReactTestUtils.SimulateNative. Eles nunca foram documentados, não cumprem exatamente o que seus nomes indicam e não funcionam com as alterações que fizemos no sistema de eventos. Se você deseja uma maneira conveniente de disparar eventos nativos do navegador em testes, verifique a Biblioteca de testes do React.

Instalação

Incentivamos você a experimentar o React 17.0 Release Candidate em breve e levantar quaisquer problemas para os problemas que você pode encontrar na migração. Lembre-se de que um candidato a lançamento tem mais probabilidade de conter bugs do que um lançamento estável, portanto, não o implante na produção ainda.

Para instalar o React 17 RC com npm, execute:

npm install react@17.0.0-rc.3 react-dom@17.0.0-rc.3

Para instalar o React 17 RC com Yarn, execute:

yarn add react@17.0.0-rc.3 react-dom@17.0.0-rc.3

Também fornecemos compilações UMD do React por meio de um CDN:

<script crossorigin src="https://unpkg.com/react@17.0.0-rc.3/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@17.0.0-rc.3/umd/react-dom.production.min.js"></script>

Consulte a documentação para instruções de instalação detalhadas.

Changelog

React

• Adicione react/jsx-runtime e react/jsx-dev-runtime para que a nova transformação JSX. (@lunaruan em #18299)
• Construa pilhas de componentes a partir de quadros de erro nativos. (@sebmarkbage em #18561)
• Permite especificar displayName no contexto para pilhas melhoradas. (@eps1lon em #18224)
• Impedir que 'use strict' vaze nos pacotes UMD. (@koba04 em #19614)
• Pare de usar fb.me para redirecionamentos. (@cylim em #19598)

React DOM

• Delegar eventos para raízes ao invés de document. (@trueadm em #18195 e outros)
• Limpe todos os efeitos antes de executar os próximos efeitos. (@bvaughn em #17947)
• Execute as funções de limpeza useEffect de forma assíncrona. (@bvaughn em #17925)
• Use o navegador focusin e focusout para onFocus e onBlur. (@trueadm em #19186)
• Faça com que todos os eventos Capture usem a fase de captura do navegador. (@trueadm em #19221)
• Não emule o propagação do evento onScroll. (@gaearon em #19464)
• Lance se o componente forwardRef ou memo retornar undefined. (@gaearon em #19550)
• Remova o pool de eventos. (@trueadm em #18969)
• Pare de expor detalhes internos que não serão necessários para o React Native Web. (@necolas em #18483)
• Anexe todos os event listeners conhecidos quando o root for montado. (@gaearon em #19659)
• Desative o console na segunda passagem de renderização do modo DEV de renderização dupla. (@sebmarkbage em #18547)
• Descontinue a API ReactTestUtils.SimulateNative não documentada e confusa. (@gaearon em #13407)
• Renomeie os nomes dos campos privados usados nos internos. (@gaearon em #18377)
• Não chame a API User Timing no desenvolvimento. (@gaearon em #18417)
• Desative o console durante a renderização repetida no modo estrito. (@sebmarkbage em #18547)
• No Modo Estrito, os componentes de renderização dupla sem Hooks também. (@eps1lon em #18430)
• Permitir chamar ReactDOM.flushSync durante os métodos de ciclo de vida (mas avisar). (@sebmarkbage em #18759)
• Adicione a propriedade code aos objetos de evento do teclado. (@bl00mber em #18287)
• Adicione a propriedade disableRemotePlayback para os elementos video. (@tombrowndev em #18619)
• Adicione a propriedade enterKeyHint para elementos input. (@eps1lon em #18634)
• Avisar quando nenhum valor é fornecido para <Context.Provider>. (@charlie1404 em #19054)
• Avisa quando os componentes memo ou forwardRef retornam undefined. (@bvaughn em #19550)
• Melhore a mensagem de erro para atualizações inválidas. (@JoviDeCroock em #18316)
• Exclua forwardRef e memo dos frames da pilha. (@sebmarkbage em #18559)
• Melhore a mensagem de erro ao alternar entre entradas controladas e não controladas. (@vcarl em #17070)
• Mantenha onTouchStart, onTouchMove e onWheel passivos. (@gaearon em #19654)
• Corrigir setState pendurado em desenvolvimento dentro de um iframe fechado. (@gaearon em #19220)
• Corrigir o resgate de renderização para componentes lazy com defaultProps. (@jddxf em #18539)
• Corrigir um aviso de falso positivo quando hazouslySetInnerHTML é undefined. (@eps1lon em #18676)
• Corrigir os utilitários de teste com implementação require não padrão. (@just-boris em #18632)
• Corrigir onBeforeInput relatando um event.type incorreto. (@eps1lon em #19561)
• Corrigir o event.relatedTarget relatado como undefined no Firefox. (@claytercek em #19607
• Corrigir “erro não especificado” no IE11. (@hemakshis em #19664)
• Corrigir a renderização em uma root shadow. (@ Jack-Works em #15894)
• Corrigir polyfill movementX / Y com eventos de captura. (@gaearon em #19672)
• Use a delegação para eventos onSubmit e onReset. (@gaearon em #19333)
• Melhore o uso de memória. (@trueadm em #18970)

Servidor React DOM

• Torne o comportamento useCallback consistente com useMemo para o renderizador do servidor. (@alexmckenley em #18783)
• Fix state leaking when a function component throws. (@pmaccart em #19212)

Teste Renderização React

• Melhorar a mensagem de erro findByType. (@henryqdineen em #17439)

Modo simultâneo (Experimental)

• Renovar as heurísticas de lote de prioridade. (@acdlite em #18796)
• Adicione o prefixo unstable_ antes das APIs experimentais. (@acdlite em #18825)
• Remova unstable_discreteUpdates e unstable_flushDiscreteUpdates. (@trueadm em #18825)
• Remova o argumento timeoutMs. (@acdlite em #19703)
• Desabilite <div hidden /> pré-renderizando em favor de uma API futura diferente. (@acdlite em #18917)
• Adicione unstable_expectedLoadTime no Suspense para a árvores do CPU-bound. (@acdlite em #19936)
• Adicione um Hook experimental unstable_useOpaqueIdentifier. (@lunaruan em #17322)
• Adicione uma API experimental unstable_startTransition. (@rickhanlonii em #19696)
• Usar act em o renderizador de teste não libera mais os fallbacks do Suspense. (@acdlite em #18596)
• Use o tempo limite de renderização global para CPU Suspense. (@sebmarkbage em #19643)
• Limpe o conteúdo raiz existente antes de montar. (@bvaughn em #18730)
• Corrija um bug com limites de erro. (@acdlite em #18265)
• Corrigir um bug que causava atualizações perdidas em uma árvore suspensa. (@acdlite em #18384 e #18457)
• Corrigir um bug que causava a queda das atualizações da fase de renderização. (@acdlite em #18537)
• Corrigir um bug em SuspenseList. (@sebmarkbage em #18412)
• Corrigido um bug que fazia com que o recurso Suspense fosse exibido muito cedo. (@acdlite em #18411)
• Corrigir um bug com componentes de classe dentro de SuspenseList. (@sebmarkbage em #18448)
• Corrigir um bug com entradas que podem fazer com que as atualizações sejam descartadas. (@jddxf em #18515 e @acdlite em #18535)
• Corrigir um bug que fazia o fallback do Suspense travar. (@acdlite em #18663)
• Não corte a cauda de um SuspenseList se estiver hidratando. (@sebmarkbage em #18854)
• Corrigir um bug em useMutableSource que pode acontecer quandogetSnapshot muda. (@bvaughn em #18297)
• Corrigido um bug de tearing em useMutableSource. (@bvaughn em #18912)
• Avisa se estiver chamando setState fora da renderização, mas antes do commit. (@sebmarkbage em #18838)

Novos Avisos

Avisos para algumas atualizações durante a renderização

Um componente React não deve causar efeitos colaterais em outros componentes durante a renderização.

É suportado chamar setState durante a renderização, mas somente para o mesmo componente. Se você chamar setState durante uma renderização em um componente diferente, você verá um aviso:

Warning: Cannot update a component from inside the function body of a different component.

Este aviso ajudará a encontrar erros de aplicativos causados ​​por alterações não intencionais do estado. Nos raros casos em que você deseja alterar intencionalmente o estado de outro componente como resultado da renderização, é possível agrupar a chamada do setState dentro do useEffect.

Avisos para regras de estilo conflitantes

Ao aplicar dinamicamente um style que contém versões longhand e shorthand de propriedades CSS, combinações específicas de atualizações podem causar estilos inconsistentes. Por exemplo:

<div style={toggle ? 
  { background: 'blue', backgroundColor: 'red' } : 
  { backgroundColor: 'red' }
}>
  ...
</div> 

Você pode esperar que essa <div> tenha sempre um fundo vermelho, não importa o valor de toggle. No entanto, ao alternar o valor de toggle entre true e false, a cor de fundo começa como red, então alterna entre transparent e blue, como você pode ver nessa demo.

O React agora detecta regras de estilo conflitantes e registra um aviso. Para corrigir um problema, não misture versões shorthand e longhand da mesma propriedade CSS na prop style.

Avisos para algumas string refs depreciadas

String Refs é uma API legada que é desencorajada e será depreciada no futuro:

<Button ref="myRef" />

(Não confunda String Refs com refs em geral, o que permanece totalmente suportado.)

No futuro, forneceremos um script automatizado (um “codemod”) para migrar para longe das referências de string. No entanto, alguns casos raros não podem ser migrados automaticamente. Esta versão adiciona um novo aviso apenas para esses casos antes da depreciação.

Por exemplo, ele será acionado se você usar String Refs junto com o padrão Render Prop:

class ClassWithRenderProp extends React.Component {
  componentDidMount() {
    doSomething(this.refs.myRef);
  }
  render() {
    return this.props.children();
  }
}

class ClassParent extends React.Component {
  render() {
    return (
      <ClassWithRenderProp>
        {() => <Button ref="myRef" />}
      </ClassWithRenderProp>
    );
  }
}

Um código como esse geralmente indica bugs. (Você pode esperar que a ref esteja disponível em ClassParent, mas em vez disso, é colocado em ClassWithRenderProp).

Você provavelmente não tem código como este. Se você faz e é intencional, converta-o para React.createRef() em vez de:

class ClassWithRenderProp extends React.Component {
  myRef = React.createRef();
  componentDidMount() {
    doSomething(this.myRef.current);
  }
  render() {
    return this.props.children(this.myRef);
  }
}

class ClassParent extends React.Component {
  render() {
    return (
      <ClassWithRenderProp>
        {myRef => <Button ref={myRef} />}
      </ClassWithRenderProp>
    );
  }
}

Nota

Para ver este aviso, você precisa ter o babel-plugin-transform-react-jsx-self instalado nos seus plugins Babel. Ele deve ser ativado apenas no modo de desenvolvimento.

Se você usa o Create React App ou tem a predefinição “react” com o Babel 7+, você já tem esse plug-in instalado por padrão.

Depreciando React.createFactory

React.createFactory é um helper legado para criar elementos React. Esta versão adiciona um aviso de depreciação ao método. Ele será removido em uma versão major futura.

Substitua os usos de React.createFactory com JSX regular. Como alternativa, você pode copiar e colar esse auxiliar de uma linha ou publicá-lo como uma biblioteca:

let createFactory = type => React.createElement.bind(null, type);

Faz exatamente a mesma coisa.

Depreciando ReactDOM.unstable_createPortal em favor de ReactDOM.createPortal

Quando o React 16 foi lançado,createPortal tornou-se uma API oficialmente suportada.

No entanto, mantivemos unstable_createPortal como um alias suportado para manter as poucas bibliotecas que o adotaram funcionando. Agora estamos depreciando o alias instável. Use createPortal diretamente em vez de unstable_createPortal. Tem exatamente a mesma assinatura.

Outras Melhorias

Pilhas de componentes nos avisos de hidratação

O React adiciona pilhas de componentes a seus avisos de desenvolvimento, permitindo que os desenvolvedores isolem bugs e depurem seus programas. Esta versão adiciona pilhas de componentes a vários avisos de desenvolvimento que não os tinham anteriormente. Como exemplo, considere este aviso de hidratação das versões anteriores:

Embora esteja apontando um erro no código, não está claro onde o erro existe e o que fazer em seguida. Esta versão adiciona uma pilha de componentes a este aviso, o que faz com que fique assim:

Isso deixa claro onde está o problema e permite localizar e corrigir o bug mais rapidamente.

Correções de bugs importantes

Esta versão contém algumas outras melhorias importantes:

• No Modo Estrito de Desenvolvimento, o React chama os métodos do ciclo de vida duas vezes para eliminar possíveis efeitos colaterais indesejados. Esta versão adiciona esse comportamento a shouldComponentUpdate. Isso não deve afetar a maioria dos códigos, a menos que você tenha efeitos colaterais em shouldComponentUpdate. Para corrigir isso, mova o código com efeitos colaterais para componentDidUpdate.
• No Modo Estrito de Desenvolvimento, os avisos para o uso da API de contexto legada não incluíam a pilha do componente que acionou o aviso. Esta versão adiciona a pilha ausente ao aviso.
• onMouseEnter agora não é disparado em elementos <button> desabilitados.
• O ReactDOM tinha uma exportação de version ausente desde que publicamos a v16. Esta versão adiciona de volta. Não recomendamos o uso na lógica do aplicativo, mas é útil ao depurar problemas com incompatibilidade / várias versões do ReactDOM na mesma página.

Agradecemos a todos os colaboradores que ajudaram a resolver e solucionar esses e outros problemas. Você pode encontrar o changelog completo abaixo.

Instalação

React

O React v16.13.0 está disponível no registro npm.

Para instalar o React 16 com o Yarn, execute:

yarn add react@^16.13.0 react-dom@^16.13.0

Para instalar o React 16 com npm, execute:

npm install --save react@^16.13.0 react-dom@^16.13.0

Também fornecemos compilações UMD do React por meio de uma CDN:

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Consulte a documentação para instruções detalhadas de instalação.

Changelog

React

• Avisa quando uma string ref é usada de uma maneira que não seja compatível com um futuro codemod (@lunaruan in #17864)
• Deprecia React.createFactory() (@trueadm in #17878)

React DOM

• Avisa quando houver alterações style podem causar uma colisão inesperada (@sophiebits em #14181, #18002)
• Avisa quando um componente de função é atualizado durante a fase de renderização de outro componente (@acdlite em #17099)
• Depreciado unstable_createPortal (@trueadm em #17880)
• Conserta onMouseEnter sendo acionado nos botões desativados (@AlfredoGJ em #17675)
• Chama shouldComponentUpdate duas vezes ao desenvolver em StrictMode (@bvaughn em #17942)
• Adiciona propriedade version para ReactDOM (@ealush em #15780)
• Não chamar toString() em dangerouslySetInnerHTML (@sebmarkbage em #17773)
• Mostra pilhas de componentes em mais avisos (@gaearon em #17922, #17586)

Modo Concorrente (Experimental)

• Avisa sobre usos problemáticos de ReactDOM.createRoot() (@trueadm em #17937)
• Retira ReactDOM.createRoot() parâmetros de retorno de chamada e avisos adicionais sobre o uso (@bvaughn em #17916)
• Não agrupe o trabalho ocioso / fora da tela com outro trabalho (@sebmarkbage em #17456)
• Ajusta heurística de limite de processamento do SuspenseList (@sebmarkbage em #17455)
• Adiciona prioridades de plugins de eventos ausentes (@trueadm em #17914)
• Conserta isPending somente sendo verdadeiro ao fazer a transição de dentro de um evento de input (@acdlite em #17382)
• Conserta componentes React.memo que descartam atualizações quando interrompidos por uma atualização de prioridade mais alta (@acdlite em #18091)
• Não avise ao suspender com a prioridade errada (@gaearon em #17971)
• Corrige um bug com atualizações de rebasing (@acdlite e @sebmarkbage em #17560, #17510, #17483, #17480)

Esse artigo será mais relevante para pessoas que trabalham com as bibliotecas de obtenção de dados (data fetching) para React.

Mostramos como integrar melhor elas com o Modo Concorrente e o Suspense. Os padrões introduzidos aqui são baseados no Relay — nossa biblioteca para construir interfaces de usuário orientadas a dados com GraphQL. De qualquer forma, as ideias desse artigo se aplicam a outros clientes GraphQL também assim como bibliotecas que usam REST ou outras abordagens.

Esse artigo é dedicado aos autores de bibliotecas. Se você for principalmente desenvolvedor de aplicações, você ainda pode encontrar ideias interessantes aqui, mas não se sinta obrigado a lê-lo inteiramente.

Vídeos de Talks

Se você preferir assistir vídeos, algumas das ideias desse artigo foram abordadas em diversas apresentações da React Conf 2019:

• Obtenção de Dados com Suspense no Relay por Joe Savona
• Contruindo o Novo Facebook com React e Relay por Ashley Watkins
• React Conf Keynote por Yuzhi Zheng

Esse artigo apresenta um mergulho na implentação de uma biblioteca de obtenção de dados com Suspense.

Colocando a Experiência de Usuário como Prioridade

A equipe do React e a comunidade tem constantemente enfatizado a experiência do desenvolvedor: garantindo que o React tenha boas mensagens de erro, focando em componentes como uma maneira de pensar localmente no comportamento do app, desenvolvendo APIs que são previsíveis e encorajando o correto uso via design, etc. Mas nós não temos difundido o suficiente as melhores práticas para garantir uma ótima experiência de usuário em grandes aplicações.

Por exemplo, a equipe do React tem focado na performance da biblioteca e provido ferramentas para desenvolvedores debugarem e refinarem a performance da aplicação (ex. React.memo). Mas nós não temos opinado sobre padrões de alto nível que fazem a diferença entre aplicativos rápidos e fluídos e aplicativos lentos e travados. Nós sempre queremos garantir que o React se mantenha acessível a novos usuários e suporte vários de casos uso — nem todo app tem que ser “super” rápido. Mas como uma comunidade nós podemos e devemos sonhar alto. Nós devemos fazer ser tão fácil quanto possível construir aplicativos que iniciam rápido e continuam rápidos, mesmo quando eles crescem em complexidade, para usuários utilizando uma variedade de dispositivos e redes no mundo todo.

Modo Concorrente e Suspense são funcionalidades experimentais que podem ajudar os desenvolvedores a alcançarem esse objetivo. Nós inicialmente apresentamos eles na JSConf Iceland em 2018, intencionalmente compartilhando detalhes muito antecipadamente para dar a comunidade tempo para digerir os novos conceitos e para se prepararem para as alterações seguintes. Desde então nós completamos trabalhos correlacionados, como a nova API de Contexto e a introdução do Hooks, que foram desenhados em parte para ajudar os desenvolvedores a escreverem código que seja naturalmente mais compatível com o Modo Concorrente. Mas nós não queremos implementar essas funcionalidades e liberá-las sem garantir que funcionam. Então ao longo do ano passado, as equipes do React, Relay, infraestrutura web, e produto do Facebook têm todas colaborado fortemente para construir uma nova versão do facebook.com que integre profundamente o Modo Concorrente e o Suspense para criar uma experiência com uma sensação mais fluída e similar a de um app.

Graças a esse projeto, nós estamos mais confiantes do que nunca de que o Modo Concorrente e o Suspense podem tornar mais fácil entregar uma experiência de usuário ótima e rápida. Mas fazer isso requer repensar como nós abordamos o carregamento do código e dos dados em nossos apps. Efetivamente toda a obtenção de dados no novo facebook.com é realizada pelo Relay Hooks — novas APIs do Relay baseadas em Hooks que integram com o Modo Concorrente e o Suspense sem configurações adicionais.

Relay Hooks — e GraphQL — não são para todos, e tudo bem com isso! Através do nosso trabalho nessas APIs nós identificamos um conjunto de padrões em geral para utilizar com Suspense. Mesmo que o Relay não se encaixe para você, nós acreditamos que os padrões chave que nós introduzimos com o Relay Hooks podem ser adaptados para outras bibliotecas

Melhores Práticas com Suspense

É tentador focar apenas no tempo total de inicialização de um app — mas ocorre que a percepção de performance pelo usuário é determinada por mais do que o tempo absoluto de carregamento. Por exemplo, quando comparados dois aplicativos com o mesmo tempo absoluto de inicialização, nossos estudos mostram que os usuários geralmente irão perceber aquele que tiver menos estados de carregamento intermediários e menos alterações de layout como o que carrega mais rápido. Suspense é uma ferramenta poderosa por orquestrar cuidadosamente uma elegante sequência de carregamento com poucos, e bem definidos, estados que revelam progressivamente o conteúdo. Mas melhorar a performance percebida vai além disso — nossos apps não deveriam demorar uma eternidade para obter todo o código, dados, imagens, e outros artefatos.

A abordagem tradicional para carregar dados nos apps React envolvem o que nos referimos como “renderização-conforme-você-busca”. Primeiro nós renderizamos um componente com um spinner, então carregamos dados na montagem (componentDidMount ou useEffect), e finalmente atualizamos para renderizar os dados resultantes. É certamente possível usar esse padrão com Suspense: ao invés de inicialmente renderizar um placeholder por si mesmo, um componente pode “suspender” — indicar ao React que ele não está pronto ainda. Isso irá dizer ao React para buscar o ancestral mais próximo <Suspense fallback={<Placeholder/>}>, e renderizar o seu fallback no lugar. Se você viu os demos do Suspense anteriormente este exemplo pode parecer familiar — é como nós originalmente imaginamos usar o Suspense para obtenção de dados.

Ocorre que esta abordagem tem algumas limitações. Considere uma página que mostra uma postagem de mídia social feita por um usuário, com comentários nessa postagem. Ela pode ser estruturada como um componente <Post> que renderiza tanto o corpo da postagem como a <CommentList> para mostrar os comentários. Usando a abordagem de renderização-conforme-você-busca descrita acima para implementar isso pode causar idas e voltas sequenciais (muitas vezes conhecido como uma “cachoeira”). Primeiro os dados para o componente <Post> seriam obtidos e então os dados para a <CommentList>, aumentando o tempo que para mostrar a página completamente.

Há também outra desvantagem muitas vezes esquecida nessa abordagem. Se o <Post> requisita (ou importa) o componente <CommentList> de maneira completa, nosso app terá de esperar para mostrar o corpo da postagem enquanto o código para os comentários é baixado. Nós poderíamos carregar a <CommentList> de maneira preguiçosa, mas dessa forma nós iríamos atrasar a obtenção dos dados dos comentários e aumentar o tempo para exibir a página inteira. Como nós resolvemos esse problema sem comprometer a experiência do usuário?

Renderização Conforme Você Busca

A abordagem de renderização-conforme-você-busca é amplamente utilizada pelos apps React atualmente e pode certamente ser usada para criar ótimos apps. Mas nós conseguiríamos fazer ainda melhor? Vamos voltar um passo atrás e considerar nosso objetivo.

No exemplo acima do <Post>, nós idealmente deveríamos mostrar o conteudo mais importante — o corpo da postagem — o mais rápido possível, sem impactar negativamente o tempo para mostrar a página completamente (incluindo comentários). Vamos considerar as restrições em qualquer solução e observar como nós podemos atendê-las:

• Mostrar o conteúdo mais importante (o corpo da postagem) o mais rápido possíve significa que nós precisamos carregar o código e os dados para a visualização de forma incremental. Nós não queremos bloquear a visualização do corpo da postagem enquanto o código da <CommentList> é baixado, por exemplo.
• Ao mesmo tempo nós não queremos aumentar o tempo para exibição da página completa incluindo comentários. Então nós precisamos começar a carregar o código e os dados para os comentários o mais rápido possível, idealmente em paralelo ao carregamento do corpo da postagem.

Isso pode soar difícil de alcançar — mas essas restrições são na verdade incrivelmente facilitadoras. Elas descartam uma série de abordagens e nos desenham um rascunho da solução. Isso nós leva aos padrões chave que nós implementamos no Relay Hooks, e que podem ser adaptados para outras biblotecas de obtenção de dados. Veremos cada desses padrões de maneira a entender como podem nos ajudar a alcançar nosso objetivo de experiências de carregamento rápidas e encatadoras:

1. Dados em paralelo e árvores de visualização
2. Obtenção de dados em manipuladores de evento
3. Carregar dados incrementalmente
4. Tratar código como dado

Dados em Paralelo e Árvores de Visualização

Uma das coisas mais atraentes no padrão de renderização-conforme-você-busca é que ele combina quais dados o componente precisa com como renderizar esses dados. Essa combinação é ótima — um exemplo de como faz sentido agrupar código por responsabilidades e não por tecnologias. Todos os problemas que nós vimos acima foram sobre quando nós obtemos os dados nessa abordagem: após a renderização. Nós precisamos precisamos ser capazes de obter dados antes de renderizar o componente. A única forma de alcançar isso é extraindo as dependências de dados em dados em paralelo e árvores de visualização.

Aqui mostramos como isso funciona no Relay Hooks. Continuando nosso exemplo de uma postagem de mídia social com corpo e comentários, aqui está como definimos isso no Relay Hooks:

// Post.js
function Post(props) {
  // Dado uma referência para alguma postagem - `props.post` - *de quais* dados
  // nós precisamos sobre essa postagem?
  const postData = useFragment(graphql`
    fragment PostData on Post @refetchable(queryName: "PostQuery") {
      author
      title
      # ...  mais campos ...
    }
  `, props.post);

  // Agora que nós temos os dados, como renderizá-lo?
  return (
    <div>
      <h1>{postData.title}</h1>
      <h2>by {postData.author}</h2>
      {/* mais campos  */}
    </div>
  );
}

Embora o GraphQL esteja escrito junto ao componente, Relay tem um passo de build (Compilador do Relay) que extrai essas dependências-de-dados em arquivos separados e agrega o GraphQL para cada visualização em uma única consulta. Então nós obtemos os benefícios de combinar responsabilidades, enquanto no tempo de execução temos dados em paralelo e árvores de visualização. Outras bibliotecas poderiam alcançar resultados similares ao permitir que os desenvolvedores definam lógica de obtenção de dados em um arquivo irmão (talvez Post.data.js), ou então integrar com um bundler para permitir definição de dependência de dados com código de interface de usuário e automaticamente extraí-lo, de maneira semelhante ao Compilador do Relay.

O segredo é que independente da tecnologia que estamos usando para carregar nossos dados — GraphQL, REST, etc — nós podemos separar quais dados carregar de como e quando fazê-lo. Mas uma vez feito isso, como e quando nós carregamos nossos dados?

Obtenção de Dados em Manipuladores de Evento

Imagine que nós estamos para navegar da listagem de postagens de um usuário para a página de uma postagem específica. Nós vamos precisar baixar o código para aquela página — Post.js — e também obter seus dados.

Aguardar até que a gente renderize os dados gera os problemas que nós vimos acima. O segredo é começar a obter o código e os dados para a nova visualização no mesmo manipulador de evento que dispara a visualização. Nós ainda podemos obter os dados com nosso roteador — se nosso roteador suporta pré-carregamento de dados para as rotas — ou no evento de clique no link que disparou a navegação. Vale lembrar que os colegas do React Router já trabalharam arduamente para construir APIs para suportarem pré-carregamento de dados para rotas. Mas outras bibliotecas de roteamento podem implementar essa ideia também.

Conceitualmente, nós queremos que a definição de cada rota inclua duas coisas: qual componente renderizar e que dados pré-carregar, como uma função de rota/parâmetros de url. Aqui está o que esta definição de rota pode parecer. Este exemplo é um pouco inspirado pelas definições de rota do React Router e principalmente se dedica a demonstrar o conceito, não uma API específica:

// PostRoute.js (GraphQL version)

// Consulta do Relay para carregamento dos dados do Post
import PostQuery from './__generated__/PostQuery.graphql';

const PostRoute = {
  // uma expressão que associa qual rota tratar
  path: '/post/:id',

  // que componente renderizar para essa rota
  component: React.lazy(() => import('./Post')),

  // dados a serem carregados para essa rota, como uma função dos parâmetros
  // da rota
  prepare: routeParams => {
    // Relay extrai consultas de componentes, nos permitindo referenciar
    // as dependências de dados -- árvore de dados -- de fora.
    const postData = preloadQuery(PostQuery, {
      postId: routeParams.id,
    });

    return { postData };
  },
};

export default PostRoute;

Por definição, um roteador pode:

• Associar uma URL a uma definição de rota.
• Chamar a função prepare() para iniciar o carregamento dos dados da rota. Note que prepare() é síncrona — nós não queremos esperar pelos dados, dado que nós queremos começar a renderizar as partes mais importantes da visualização (como o corpo da postagem) o mais rápido que possível.
• Passar os dados pré-carregados para o componente. Se o componente estiver pronto — a importação dinâmica do React.lazy terminou — o componente irá renderizar e tentar acessar os seus dados. Do contrário, o React.lazy irá suspender até que o código esteja pronto.

Esta abordagem pode ser generalizada para outras soluções de obtenção de dados. Um app que usa REST poderia definir uma rota dessa forma:

// PostRoute.js (versão em REST)

// Lógica escrita manualmente para carregamento dos dados para o componente
import PostData from './Post.data';

const PostRoute = {
  // uma expressão que associa qual rota tratar
  path: '/post/:id',

  // que componente renderizar para essa rota
  component: React.lazy(() => import('./Post')),

  // dados a serem carregados para essa rota, como uma função dos parâmetros
  // da rota
  prepare: routeParams => {
    const postData = preloadRestEndpoint(
      PostData.endpointUrl, 
      {
        postId: routeParams.id,
      },
    );
    return { postData };
  },
};

export default PostRoute;

Esta mesma abordagem pode ser empregada não apenas para roteamento, mas em outros lugares onde nós queiramos mostrar conteúdo de maneira preguiçosa ou baseada na interação do usuário. Por exemplo, um componente de aba poderia carregar completamente os dados e o código para a primeira aba, e então usar o mesmo padrão acima para carregar o código e os dados para as outras abas que estão no manipulador de evento de troca de aba. Um componente que mostra um modal poderia pré-carregar o código e os dados para o modal no manipulador de clique que dispara a abertura do modal, e assim por diante.

Uma vez que implementamos a habilidade de começar a carregar código e dados de uma visualização de maneira independente, nós temos a opção de ir um passo além. Considere um componente <Link to={path} /> que faz o link para uma rota. Se o usuário passa sobre este link, existe uma chance razoável de que ele irá clicá-lo. E se ele pressionar o mouse, existe uma chance ainda maior de que ele irá completar o clique. Se nós podemos carregar o código e os dados para uma visualização depois de o usuário clicar, nós também podemos iniciar o trabalho antes deles clicarem, começando a preparar a visualização.

O melhor de tudo, nós podemos centralizar essa lógica em poucos lugares chave — um roteador ou em componentes centralizadores de interação com o usuário — e obter quaisquer benefícios de performance automaticamente em todo nosso app. Claro que pré-carregar nem sempre é benéfico. É algo que um aplicativo pode otimizar baseado no dispositivo do usuário ou velocidade de rede para evitar consumir os planos de dados do usuário. Mas este padrão torna mais fácil centralizar a implementação do pré-carregamento e a decisão de quando habilitá-lo ou não.

Carregar Dados Incrementalmente

Os padrões acima — dados em paralelo/árvores de visualização e obtenção em manipuladores de evento — nos permitem iniciar o carregamento dos dados de uma visualização antecipadamente. Mas nós ainda queremos poder mostrar as partes mais importantes da visualização sem ter que esperar por todos os nossos dados. No Facebook nós implementamos o suporte para isso no GraphQL e Relay na forma de algumas novas diretivas de GraphQL (anotações que afetam quando/como os dados são entregues, mas não quais dados). Essas novas diretivas, chamadas @defer e @stream, nos permitem recuperar dados de maneira incremental. Por exemplo, considere nosso componente <Post> acima. Nós queremos mostrar o corpo sem ter que esperar que os comentários estejam prontos. Nós podemos alcançar isso com @defer e <Suspense>:

// Post.js
function Post(props) {
  const postData = useFragment(graphql`
    fragment PostData on Post {
      author
      title

      # obter dados para os comentários, mas sem bloquear até que estejam carregados
      ...CommentList @defer
    }
  `, props.post);

  return (
    <div>
      <h1>{postData.title}</h1>
      <h2>by {postData.author}</h2>
      {/* @defer trabalha naturalmente com <Suspense> para criar uma interface de usuário não bloqueada também */}
      <Suspense fallback={<Spinner/>}>
        <CommentList post={postData} />
      </Suspense>
    </div>
  );
}

Aqui, nosso servidor GraphQL devolve os resultados por stream, primeiro retornando os campos author e title e então retornando os dados de comentário quando estiver pronto. Nós envolvemos a <CommentList> em uma tag <Suspense> então nós podemos renderizar o corpo da postagem antes da <CommentList> e seus dados estarem prontos. Esse padrão pode ser aplicado a outras biblotecas. Por exemplo, apps que chamam uma API REST podem fazer requisições em paralelo para obter os dados para o corpo e comentários para uma postagem evitando bloquear até que todos os dados estejam prontos.

Tratar Código Como Dados

Mas ainda tem uma coisa faltando. Nós mostramos como pré-carregar dados para uma rota — mas e o código? O exemplo acima nos enganou um pouco e usou React.lazy. De qualquer forma, React.lazy é, como o nome indica, preguiçoso. Ele não irá começar a baixar o código até que o componente preguiçoso esteja renderizado — é uma “obtenção-de-dados-na-renderização” para código!

Para resolver isso, a equipe do React está considerando APIs que nos permitiriam dividir o bundle e pré-carregar completamente o código também. Isso permitiria um usuário passar de alguma forma um componente preguiçoso para uma rota, e a rota disparar o carregamento do código e dos seus dados o mais antecipadamente possível.

Resumindo

Para recaptular, atingir uma ótima experiência de usuário significa que nós precisamos começar a carregar código e dados o mais antecipadamente possível, mas sem esperar que tudo seja completado. Dados em paralelo e árvores de visualização nos permitem carregar os dados para uma visualização em paralelo com o carregamento da própria visualização (código). Obtenção de dados em um manipulador de eventos significa que nós podemos começar a carregar os dados o mais antecipadamente possível, e otimamente até mesmo pré-carregar uma visualização quando nós tivermos confiança suficiente de que o usuário irá navegar para ela. Carregar dados de maneira incremental nos permite carregar os dados mais importantes antecipadamente sem atrasar a obtenção de dados de menos importância. E tratar código como dados — e pré-carregar esse código com APIs similares — nos permite carregá-lo de maneira antecipada também.

Utilizando Esses Padrões

Esses padrões não são apenas ideias — nós os implementamos no React Hooks e estamos usando eles em produção ao longo do novo facebook.com (o que está atualmente em teste beta). Se você estiver interessado em utilizá-lo ou aprender mais sobre esses padrões, aqui estão algumas referências:

• A documentação do Modo Concorrente do React aborda como utilizar o Modo Concorrente e o Suspense e detalha melhor vários desses padrões. É uma ótima referência para aprender mais sobre as APIs e casos de uso que elas suportam.
• A versão experimental do Relay Hooks implementa os padrões descritos aqui.

• Nós implementamos dois aplicativos de exemplo que demonstram esses conceitos:

  • O aplicativo exemplo do Relay Hooks utiliza a API GraphQL pública do GitHub para implementar um aplicativo simples de rastreamento de issues. Ele inclui suporte a rotas aninhadas com pré-carregamento de dados e código. O código está totalmente comentado — nós encorajamos clonar o repositório, executar o aplicativo localmente, e explorar como ele funciona.
  • Nós também temos uma versão de aplicativo não-GraphQL que demonstra como esses conceitos podem ser aplicados para outras bibliotecas de obtenção de dados.

Mesmo que as APIs do Modo Concorrente e Suspense ainda sejam experimentais, nós estamos confiantes que as ideias desse artigo são comprovadas na prática. De qualquer forma, nós entendemos que o Relay e GraphQL não são aplicáveis a todos. E tudo bem! Nós estamos explorando como generalizar esses padrões para abordagens como REST, e também explorando ideias para uma API mais genérica (isto é, não-GraphQL) para composição de árvores de dependência de dados. Enquanto isso, estamos animados por ver que novas bibliotecas irão surgir implementando os padrões descritos nesse artigo para criar de maneira mais fácil, experiências de usuário rápidas.

Este documento será mais relevante para desenvolvedores que trabalham em frameworks, bibliotecas, ou ferramentas de desenvolvedor. Os desenvolvedores que usam React principalmente para criar aplicações voltadas para o usuário final não precisam se preocupar com nossos canais de prerelease.

React conta com uma próspera comunidade de código aberto para registrar relatórios de bugs, abrir pull requests e enviar RFCs. Para incentivar feedback, às vezes compartilhamos builds especiais do React que incluem recursos não lançados.

Como a fonte de verdade para o React é nosso repositório público no GitHub, é sempre possível construir uma cópia do React que possua as últimas alterações. Entretanto é muito mais fácil para os desenvolvedores instalarem elas no npm, então nós ocasionalmente publicamos prereleases para o registro do npm. Um exemplo recente é a 16.7 alpha, que inclui uma versão antecipada da API Hooks.

Nós gostaríamos de tornar ainda mais fácil para os desenvolvedores testarem prereleases do React, então nós estamos formalizando nosso processo com 3 canais de release separados.

Canais de Release

A informação desse artigo também está disponível em nossa página dos Canais de Release. Nós iremos atualizar esse documento sempre que fizermos alterações no processo de release.

Cada um dos canais de release do React foram projetados para um caso de uso distinto:

• Latest é para estável, releases semver do React. É o que você recebe ao instalar o React a partir do npm. Este é o canal que você já está usando hoje. Use isso para todos as aplicações React voltadas para o usuário final.
• Next acompanha a branch master do repositório de código fonte do React. Pense nisso como candidatos a release para o próximo minor semver release. Use isso para teste de integração entre React e projetos de terceiros.
• Experimental inclui APIs experimentais e recursos que não estão disponíveis nas releases estáveis. Eles também acompanham a branch master, mas com flags de recursos adicionais ativadas. Use isso para experimentar os próximos recursos antes de serem lançados.

Todos os releases são publicados no npm, mas apenas os Latest usam versionamento semântico. Os prereleases (aqueles nos canais Next e Experimental) têm versões geradas a partir de um hash de seu conteúdo, por exemplo 0.0.0-1022ee0ec para Next e 0.0.0-experimental-1022ee0ec para Experimental.

O único canal de release oficialmente suportado para aplicações voltadas para o usuário final é o Latest. Next e Experimental releases são fornecidos apenas para fins de teste e não fornecemos garantias de que o comportamento não seja alterado entre as versões. Eles não seguem o protocolo semver que usamos para releases no Latest.

Por publicar prereleases no mesmo registro que usamos para releases estáveis, podemos tirar proveito das muitas ferramentas que suportam o fluxo de trabalho no npm, como unpkg e CodeSandbox.

Canal Latest

Latest é o canal usado para releases estáveis do React. Corresponde à tag latest no npm. É o canal recomendado para todos os apps React que são enviados para usuários reais.

Se você não tem certeza de qual canal deve usar, é o Latest. Se você é um desenvolvedor React, é isso que você já está usando.

Você pode esperar que as atualizações do Latest sejam extremamente estáveis. As versões seguem o esquema de versão semântica. Saiba mais sobre nosso compromisso com a estabilidade e a migração incremental em nossa política de versão.

Canal Next

O canal Next é um canal de prerelease que acompanha a branch master do repositório React. Usamos as prereleases no canal Next como release candidates para o canal Latest. Você pode pensar em Next como um superconjunto de Latest que é atualizado com mais frequência.

O grau de alteração entre o release mais recente do Next e a versão mais recente do Latest é aproximadamente o mesmo que você encontraria entre dois releases de minor semver. No entanto, o canal Next não está de acordo com o controle de versão semântico. Você deve esperar breaking changes ocasionais durante sucessivos releases no canal Next.

Não use prereleases em aplicações voltadas para o usuário final.

Releases no Next são publicadas com a tag next no npm. As versões são geradas a partir de um hash do conteúdo do build, por exemplo 0.0.0-1022ee0ec.

Usando o Canal Next para Testes de Integração

O canal Next foi projetado para dar suporte aos testes de integração entre React e outros projetos.

Todas as alterações no React passam por extensos testes internos antes de serem lançadas para o público. No entanto, existem inúmeros ambientes e configurações usados em todo o ecossistema React, e não é possível testar cada um deles.

Se você é o autor de um projeto de terceiros como um framework, biblioteca, ferramenta de desenvolvedor, ou qualquer tipo de infraestrutura semelhante, você pode nos ajudar a manter o React estável para seus usuários e para toda a comunidade React executando periodicamente sua suíte de testes nas alterações mais recentes. Se você estiver interessado, siga estas etapas:

• Configure um cron job usando sua plataforma de integração contínua preferida. Cron jobs são suportados ambos pelo CircleCI e pelo Travis CI.

• No cron job, atualize seus pacotes React para o release mais recente do React no canal Next, usando a tag next no npm. Usando o npm cli:

  npm update react@next react-dom@next

  Ou yarn:

  yarn upgrade react@next react-dom@next

• Execute sua suíte de testes nos pacotes atualizados.
• Se tudo passar, ótimo! Você pode esperar que seu projeto funcione com o próximo minor release do React.
• Se algo quebrar inesperadamente, por favor avise-nos criando uma issue.

Um projeto que usa esse fluxo de trabalho é Next.js. (Sem trocadilhos! Sério!) Você pode consultar a sua configuração do CircleCI como exemplo.

Canal Experimental

Como o Next, o canal Experimental é um canal de prerelease que acompanha a branch master do repositório React. Ao contrário do Next, os releases Experimental incluem recursos e APIs adicionais que não estão prontas para release maior.

Geralmente, uma atualização para Next é acompanhada por uma atualização correspondente para Experimental. Eles são baseados na mesma revisão de origem, mas são criados usando um conjunto diferente de flags de recursos.

Os releases Experimental podem ser significativamente diferentes dos releases Next e Latest. Não use releases Experimental em aplicações voltadas para o usuário final. Você deve esperar breaking changes frequentes entre releases no canal Experimental.

Releases no Experimental são publicados com a tag experimental no npm. As versões são geradas a partir de um hash do conteúdo do build, por exemplo 0.0.0-experimental-1022ee0ec.

O Que Entra em um Release Experimental?

Recursos experimentais são aqueles que não estão prontos para serem liberados ao público em geral e podem sofrer alterações drásticas antes de serem finalizados. Alguns experimentos podem nunca ser finalizados - a razão pela qual temos experimentos é testar a viabilidade das alterações propostas.

Por exemplo, se o canal Experimental existisse quando anunciamos Hooks, teríamos lançado Hooks no canal Experimental semanas antes de estarem disponíveis no Latest.

Você pode achar valioso executar testes de integração no Experimental. Isso é com você. No entanto, saiba que o Experimental é ainda menos estável que o Next. Não garantimos estabilidade entre releases Experimental.

Como Posso Aprender Mais Sobre os Recursos Experimentais?

Recursos Experimentais podem ou não ser documentados. Geralmente, os experimentos não são documentados até que estejam perto de serem lançados no Next ou no Stable.

Se um recurso não estiver documentado, ele poderá ser acompanhado por um RFC.

Publicaremos no blog do React quando estivermos prontos para anunciar novos experimentos, mas isso não significa que divulgaremos cada experimento.

Você sempre pode consultar o histórico do repositório público do GitHub para obter uma lista abrangente de alterações.

O que mudou?

Muito mudou na versão 4! Resumidamente, esta nova versão deve oferecer ganhos significantes de performance e uma experiência de navegação melhorada. Ela também oferece suporte completo para React Hooks, incluindo a possibilidade de inspecionar objetos aninhados.

Visite o tutorial interativo para testar a nova versão ou veja o changelog para vídeos de demonstração e mais detalhes.

Quais versões do React são suportadas?

react-dom

• 0-14.x: Não suportada
• 15.x: Suportada (exceto para a nova funcionalidade de filtro de componentes)
• 16.x: Suportada

react-native

• 0-0.61.x: Não suportada
• 0.62: Suportada

Como eu consigo o novo DevTools?

O React DevTools está disponível como uma extensão para Chrome e Firefox. Se você já instalou a extensão, ela deve atualizar automaticamente nas próximas horas.

Se você usa a versão independente (por exemplo, no React Native ou Safari), você pode instalar a nova versão a partir do NPM:

npm install -g react-devtools@^4

Para onde foram todos os elementos do DOM?

O novo DevTools provê uma maneira de filtrar os componentes da árvore para facilitar a navegação de hierarquias profundamente aninhadas. Host nodes (por exemplo, HTML <div>, React Native <View>) são escondidos por padrão, mas este filtro pode ser desabilitado:

Como eu volto para a versão antiga?

Se você está trabalhando com React Native na versão 60 (ou anterior), você pode instalar a versão anterior do DevTools a partir do NPM:

npm install --dev react-devtools@^3

Para versões anteriores do React DOM (v0.14 ou anterior) você precisará fazer o build da extensão a partir do código fonte:

# Faça checkout do código da extensão
git clone https://github.com/facebook/react-devtools

cd react-devtools

# Faça checkout do branch da versão anterior
git checkout v3

# Instale as dependências e faça o build da extensão descompactada
yarn install
yarn build:extension

# Siga as instruções da tela para finalizar a instalação

Muito obrigado!

Nós gostaríamos de agradecer quem testou a versão antecipada do DevTools versão 4. Seus feedbacks ajudaram a melhorar significativamente a versão inicial.

Nós ainda temos muitas funcionalidades excitantes planejadas e feedbacks são muito bem-vindos! Sinta-se a vontada para abrir uma issue no GitHub ou marcar @reactjs no Twitter.

Novas Depreciações

Renomeando Métodos de Ciclo de Vida Inseguros

Há mais de um ano, anunciamos que os métodos de ciclo de vida inseguros estão sendo renomeados:

• componentWillMount → UNSAFE_componentWillMount
• componentWillReceiveProps → UNSAFE_componentWillReceiveProps
• componentWillUpdate → UNSAFE_componentWillUpdate

O React 16.9 não contém alterações significativas e os nomes antigos continuam funcionando nesta versão. Mas agora você verá um aviso ao usar qualquer um dos nomes antigos:

Como o aviso sugere, geralmente há abordagens melhores para cada um dos métodos inseguros. No entanto, talvez você não tenha tempo para migrar ou testar esses componentes. Nesse caso, recomendamos a execução de um script “codemod” que os renomeia automaticamente:

cd seu_projeto
npx react-codemod rename-unsafe-lifecycles

(Note que ele diz npx, não npm. npx é um utilitário que vem com Node 6+ por padrão.)

A execução deste codemod substituirá os nomes antigos como componentWillMount pelos novos nomes como UNSAFE_componentWillMount:

Os novos nomes como UNSAFE_componentWillMount irão continuar a funcionar em ambos React 16.9 e em React 17.x. No entanto, o novo prefixo UNSAFE_ ajudará os componentes com padrões problemáticos a se destacarem durante os code review e depuração de código. (Se desejar, você pode desestimular ainda mais o uso dele dentro do seu aplicativo com o Strict Mode.)

Nota

Saiba mais sobre nossa política de versão e compromisso com a estabilidade.

Depreciando URLs javascript:

As URLs que começam com javascript: são uma superfície de ataque perigosa porque é fácil incluir acidentalmente uma saída não-tratada em uma tag <a href> e criar uma brecha de segurança:

const userProfile = {
  website: "javascript: alert('you got hacked')",
};
// This will now warn:
<a href={userProfile.website}>Profile</a>

Em React 16.9, esse padrão continua a funcionar, mas registrará um aviso. Se você usar javascript: na lógica das URLs, tente usar manipuladores de eventos React. (Como último recurso, você pode contornar a proteção dangerouslySetInnerHTML, mas é altamente desencorajado e muitas vezes leva a falhas de segurança.)

Em uma versão principal futura, React lançará um erro se encontrar um javascript: URL.

Depreciando Componentes “Factory”

Antes de compilar as classes JavaScript com o Babel se tornar popular, o React tinha suporte para um componente “factory” que retorna um objeto com um método render:

function FactoryComponent() {
  return { render() { return <div />; } }
}

Esse padrão é confuso porque parece muito com um componente de função - mas não é um. (Um componente de função apenas retornaria o <div /> do exemplo acima.)

Esse padrão quase nunca foi usado e o suportá-lo faz com que o React seja um pouco maior e mais lento do que o necessário. Então estamos depreciando este padrão na 16.9 e registrando um aviso se ele for encontrado. Se você confiar nele, a adição FactoryComponent.prototype = React.Component.prototype pode servir como uma solução alternativa. Alternativamente, você pode convertê-lo em uma classe ou em um componente de função.

Não esperamos que a maioria das bases de código seja afetadas por isso.

Novas Funcionalidades

Utilitário act() assíncrono para teste

O React 16.8 introduziu um novo utilitário de teste chamado act() para ajudá-lo a escrever testes que correspondam melhor ao comportamento do navegador. Por exemplo, várias atualizações de estado em um único act() são enfileiradas. Isso corresponde ao modo como o React já funciona ao manipular eventos reais do navegador e ajuda a preparar seus componentes para o futuro, no qual o React irá enfileirar atualizações com mais frequência.

No entanto, em 16.8 act() apenas suporta funções síncronas. Às vezes, você pode ter visto um aviso como este em um teste, mas não conseguiu corrigi-lo facilmente:

An update to SomeComponent inside a test was not wrapped in act(...).

No React 16.9, act() também aceita funções assíncronas, e você pode chamar o await:

await act(async () => {
  // ...
});

Isso resolve os casos restantes em que antes você não podia usar o act(), como quando a atualização do estado estava dentro de uma função assíncrona. Como resultado, você poderá corrigir todos os avisos do act() restantes em seus testes agora.

Ouvimos que não haviam informações suficientes sobre como escrever testes com act(). O novo guia Receitas de Testes descreve cenários comuns e como act() pode ajudar você a escrever bons testes. Esses exemplos usam APIs vanilla do DOM, mas você pode também usar o React Testing Library para reduzir o boilerplate de código. Muitos de seus métodos já usam act() internamente.

Por favor, informe-nos com uma issue se você se deparar com outros cenários em que act() não funciona bem para você e tentaremos ajudá-lo.

Medições de Desempenho com <React.Profiler>

Em React 16.5, introduzimos um novo React Profiler para o DevTools que ajuda a encontrar gargalos de desempenho em seu aplicativo. Em React 16.9, também estamos adicionando uma maneira programática de reunir as medições chamadas <React.Profiler>. Esperamos que a maioria dos aplicativos menores não os use, mas pode ser útil rastrear as regressões de desempenho ao longo do tempo em aplicativos maiores.

O <Profiler> mede com qual frequência uma aplicação React renderiza e qual o “custo” da renderização. Sua finalidade é ajudar identificar partes de um aplicativo que estão lentas e podem se beneficiar da otimização, como a memorização.

Um <Profiler> pode ser adicionado em qualquer lugar em uma árvore React para medir o custo de renderização dessa parte da árvore. Ele requer duas props: um id (string) e um onRender callback (função) que o React chama toda vez que um componente dentro da árvore “envia” uma atualização.

render(
  <Profiler id="application" onRender={onRenderCallback}>    <App>
      <Navigation {...props} />
      <Main {...props} />
    </App>
  </Profiler>);

Para saber mais sobre o Profiler e os parametros passado para o onRender callback, confira a documentação do Profiler.

Nota:

Profiling adiciona uma sobrecarga extra, portanto, ela é desativada na compilação de produção.

Para optar pelo profiling em produção, o React fornece uma compilação de produção especial com a criação de profiling ativo. Leia mais sobre como usar essa versão em fb.me/react-profiling.

Bugfixes Notáveis

Esta versão contém algumas outras melhorias notáveis:

• Um problema ao chamar findDOMNode() dentro de um <Suspense> foi corrigido.
• Um vazamento de memória causado pela retenção de subárvores excluídas também foi corrigido.
• Um loop infinito causado por setState em useEffect agora registra um erro. (Isto é semelhante ao erro que você vê quando você chama setState em componentDidUpdate de uma classe.)

Agradecemos a todos os colaboradores que ajudaram a identificar e corrigir esses e outros problemas. Você pode encontrar o changelog completo abaixo.

Uma atualização para o Roadmap

Em Novembro de 2018, publicamos este roteiro para as versões 16.x:

• Uma versão menor de 16.x com React Hooks (estimativa passada: Q1 2019)
• Uma versão menor de 16.x com o Concurrent Mode (estimativa passada: Q2 2019)
• Uma versão menor de 16.x com Suspense para Data Fetching (estimativa anterior: meados de 2019)

Essas estimativas eram otimistas demais e precisamos ajustá-las.

tldr: Nós lançamos os Hooks a tempo, mas estamos reagrupando o Concurrent Mode e Suspense para Data Fetching em uma única versão que pretendemos lançar ainda este ano.

Em fevereiro, nós lançamos a versão estável 16.8 incluindo o React Hooks, com suporte ao React Native um mês mais tarde. No entanto, subestimamos o trabalho de acompanhamento desta versão, incluindo as regras de lint, ferramentas de desenvolvimento, exemplos e mais documentação. Isso mudou a linha do tempo em alguns meses.

Agora que React Hooks foram lançados, o trabalho no Concurrent Mode e Suspense para Data Fetching está em pleno andamento. O novo site do Facebook que está atualmente em desenvolvimento ativo é construído sobre esses recursos. Testá-los com código real ajudou a descobrir e resolver muitos problemas antes que eles pudessem afetar os usuários de código aberto. Algumas dessas correções envolveram uma reformulação interna desses recursos, o que também fez com que a linha do tempo fosse alterada.

Com esse novo entendimento, aqui está o que planejamos fazer a seguir.

Um Lançamento em Vez de Dois

Concurrent Mode e Suspense fortalecem o novo site do Facebook que está em desenvolvimento ativo, por isso estamos confiantes de que estão perto de um estado estável tecnicamente. Agora também entendemos melhor as etapas concretas antes que elas estejam prontas para adoção de código aberto.

Originalmente, pensamos em dividir o Concurrent Mode e Suspense para Data Fetching em dois lançamentos. Descobrimos que esse sequenciamento é confuso para explicar porque esses recursos são mais relacionados do que pensávamos inicialmente. Portanto, planejamos lançar suporte para o Concurrent Mode e Suspense para Data Fetching em uma única versão.

Nós não queremos comprometer a data de lançamento novamente. Dado que confiamos em ambos no código de produção, esperamos fornecer uma versão 16.x com suporte opcional para eles este ano.

Uma Atualização na Busca de Dados

Embora o React não tenha opinião sobre como você busca dados, a primeira versão do Suspense para Data Fetching provavelmente focará a integração com bibliotecas de busca de dados opinativas. Por exemplo, no Facebook, estamos usando as APIs do Relay que se integram com o Suspense. Vamos documentar como outras bibliotecas opinativas como a Apollo podem suportar uma integração semelhante.

Na primeira versão, não pretendemos focar na solução ad-hoc “fire an HTTP request” que usamos nas demos anteriores (também conhecidas como “React Cache”). No entanto, esperamos que tanto nós como a comunidade React exploremos esse espaço nos meses após o lançamento inicial.

Uma Atualização na Renderização do Servidor

Iniciamos o trabalho no novo renderizador de servidor com capacidade para suspense, mas não esperamos que ele esteja pronto para a versão inicial do Concurrent Mode. Essa versão, no entanto, fornecerá uma solução temporária que permitirá que o renderizador do servidor existente emita HTML para fallbacks de Suspense imediatamente e, em seguida, renderize seu conteúdo real no cliente. Esta é a solução que estamos atualmente usando no Facebook até que o renderizador de streaming esteja pronto.

Por que Demora Tanto Tempo?

Lançamos as peças individuais que levaram ao Concurrent Mode quando elas se tornaram estáveis, incluindo a nova API de contexto, carregamento sob demanda com Suspense e Hooks. Também estamos ansiosos para liberar as outras partes que faltam, mas testá-las em escala é uma parte importante do processo. A resposta honesta é que isso só levou mais trabalho do que esperávamos quando começamos. Como sempre, agradecemos suas dúvidas e comentários no Twitter e em nossas issues.

Instalação

React

React v16.9.0 está disponível no registro npm.

Para instalar o React 16 com Yarn, execute:

yarn add react@^16.9.0 react-dom@^16.9.0

Para instalar o React 16 com npm, execute:

npm install --save react@^16.9.0 react-dom@^16.9.0

Nós também fornecemos compilações UMD de React via CDN:

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Consulte a documentação para instruções detalhadas de instalação.

Changelog

React

• Adiciona API do <React.Profiler> para reunir medições de desempenho programaticamente. (@bvaughn em #15172)
• Remove unstable_ConcurrentMode em favor de unstable_createRoot. (@acdlite em #15532)

React DOM

• Deprecia nomes antigos dos métodos do ciclo de vida para os UNSAFE_*. (@bvaughn em #15186 e @threepointone em #16103)
• Deprecia URLs javascript: como uma superfície de ataque comum. (@sebmarkbage em #15047)
• Deprecia componentes incomuns do “module pattern” (factory). (@sebmarkbage em #15145)
• Adiciona suporte para o atributo disablePictureInPicture em <video>. (@eek em #15334)
• Adiciona suporte para o evento onLoad no <embed>. (@cherniavskii em #15614)
• Adiciona suporte para editar estados criados por useState no DevTools. (@bvaughn em #14906)
• Adiciona suporte para alterar o Suspense no DevTools. (@gaearon em #15232)
• Avisa quando setState é chamado no useEffect, criando um loop. (@gaearon em #15180)
• Corrige um vazamento de memória. (@paulshen em #16115)
• Corrige uma falha dentro do findDOMNode dos componentes envolvidos por <Suspense>. (@acdlite em #15312)
• Corrige efeitos pendentes de ser liberados muito tarde. (@acdlite em #15650)
• Corrige ordem de argumento incorreta em uma messagem de aviso. (@brickspert em #15345)
• Corrige a ocultação dos nós de fallback do Suspense quando houver um !important no estilo. (@acdlite em #15861 e #15882)
• Melhora ligeiramente o desempenho de hidratação. (@bmeurer em #15998)

React DOM Server

• Corrige a saída incorreta para nomes de propriedades CSS customizadas do camelCase. (@bedakb em #16167)

React Test Utilities e Test Renderer

• Adiciona act(async () => ...) para testar atualizações de estado assíncronas. (@threepointone em #14853)
• Adiciona suporte para aninhamento act de diferentes renderizadores. (@threepointone em #16039 e #16042)
• Avisa no Strict Mode se os efeitos estiverem programados fora de uma chamada act(). (@threepointone em #15763 e #16041)
• Avisa ao usar act no renderizador errado. (@threepointone em #15756)

Além disso, as três linguagens a seguir concluíram a tradução da maioria dos documentos do React! 🎉

• Espanhol: es.reactjs.org
• Japonês: ja.reactjs.org
• Português do Brasil: pt-br.reactjs.org

Parabéns especiais para Alejandro Ñáñez Ortiz, Rainer Martínez Fraga, David Morales, Miguel Alejandro Bolívar Portilla, e todos os colaboradores da tradução em espanhol por serem os primeiros a completamente traduzirem as páginas principais da documentação!

Por Que a Localização é Importante?

O React já tem muitos eventos e conferências no mundo todo, mas muitos desenvolvedores não tem o inglês como idioma principal. Gostaríamos de oferecer suporte às comunidades locais que usam o React, disponibilizando nossa documentação nos idiomas mais populares.

No passado, membros da comunidade do React criaram traduções não oficiais para o chinês, árabe e coreano; Ao criar um canal oficial para essas traduções, esperamos torna-las mais fáceis de se encontrar e ajudar a garantir que os usuários do React que não falem inglês não sejam deixados para trás.

Contribuindo

Se você quiser ajudar em uma tradução atual, confira a página Idiomas e clique no link “Contribuir” para o seu idioma.

Não consegue encontrar o seu idioma? Se você deseja manter o repositório de tradução do seu idioma, siga as instruções no repositório de tradução!

Contexto

Olá a todos! Me chamo Nat! Talvez você me conheça como a moça dos poliedros. Nas últimas semanas, eu ajudei a equipe do React a coordenar os esforços da tradução. Eis como eu fiz isso.

Nossa abordagem original para as traduções foi usar uma plataforma SaaS que permite usuários a submeter traduções. Já havia um pull request para integrá-lo e minha responsabilidade original era terminar essa integração. No entanto, tivemos preocupações sobre a viabilidade dessa integração e a qualidade das traduções na plataforma no momento. Nossa principal preocupação era garantir que as traduções continuassem atualizadas com o repositório principal e não se tornassem obsoletas.

Dan me encorajou a procurar soluções alternativas, e nós nos deparamos com a forma como a Vue manteve suas traduções - através de diferentes forks dos principais repositórios no GitHub. Em particular, a tradução em japonês usou um bot para verificar periodicamente as alterações no repositório em inglês e enviar pull requests sempre que existir uma mudança.

Essa abordagem nos atraiu por vários motivos:

• Menos código de integração.
• Encorajou mantenedores ativos em cada repositório para garantir qualidade.
• Os colaboradores já tem entendimento do GitHub como plataforma e ficam motivados para contribuir diretamente a organização do React.

Começamos com um período inicial de teste em três idiomas: espanhol, japonês e chinês simplificado. Isso nos permitiu resolver quaisquer problemas no processo e garantir que futuras traduções tenham ótimas chances de sucesso. Eu queria dar a liberdade para que as equipes de tradução pudessem escolher qualquer ferramenta com a qual se sentissem à vontade. O único requisito é uma checklist que descreve a ordem de importância para a tradução de páginas.

Após o período de testes, estávamos prontos para aceitar mais idiomas. Eu criei um script para automatizar a criação de novos repositórios de idiomas, e um site, O React já esta traduzido?, para acompanhar o andamento das diferentes traduções. Começamos 10 novas traduções apenas no nosso primeiro dia!

Por causa da automação, o restante da manutenção foi em geral tranquila. Nós finalmente criamos um canal no Slack para facilitar o compartilhamento de informações pelos tradutores, e eu publiquei um guia para solidificar as responsabilidades dos mantenedores. Permitir que os tradutores conversassem entre si foi um grande benefício - por exemplo, as traduções em árabe, persa e hebraico eram capazes de se comunicar entre si para obter o texto da direita para a esquerda funcionando!

O Bot

A parte mais desafiadora foi fazer com que o bot sincronizasse as alterações da versão em inglês do site. Inicialmente, estávamos usando o bot che-tsumi criado pela equipe de tradução da Vue em japonês, mas logo decidimos construir nosso próprio bot para atender às nossas necessidades. Em particular, o bot che-tsumi trabalha com cherry picking dos novos commits. Isso acabou causando uma confusão de novos problemas que estavam interconectados, especialmente quando os Hooks foram lançados.

No final, decidimos que em vez de selecionar cada commit com cherry pick, fazia mais sentido juntar todos os novos commits e criar um novo pull request em torno de uma vez por dia. Conflitos são deixados como estão e listados no pull request, deixando uma lista de pontos para os mantenedores corrigirem.

Criar o script de sincronização foi fácil: ele faz o download do repositório traduzido, adiciona o original como remoto, puxa dele, mescla os conflitos e cria um pull request.

O problema foi encontrar um lugar para o bot rodar. Eu sou uma desenvolvedora frontend por uma razão - Heroku e seus amigos são estranhos para mim e infinitamente frustrantes. Na verdade, até esta terça-feira passada, eu estava executando o script manualmente na minha máquina local!

O maior desafio foi o espaço. Cada fork do repositório tem cerca de 100MB - o que leva alguns minutos para clonar na minha máquina local. Temos 32 forks, e os níveis gratuitos da maioria das plataformas de deployment que eu verifiquei limitam você a 512 MB de armazenamento.

Após vários cálculos no papel, encontrei uma solução: excluir cada repo depois de terminar o script e limitar a simultaneidade dos scripts de sincronização que são executados de uma vez para estarem dentro dos requisitos de armazenamento. Felizmente, os dynos no Heroku têm uma conexão à Internet muito mais rápida e são capazes de clonar até mesmo o repositório do React rapidamente.

Houve outros problemas menores que eu encontrei. Eu tentei usar o Heroku Scheduler para não ter que escrever nenhum código que fizesse watch (vigiar o repositório), mas ele acabou rodando de forma muito inconsistente, e eu tive um colapso existencial no Twitter quando não conseguia descobrir como enviar commits do dyno no Heroku. Mas no final, essa engenheira de frontend conseguiu fazer o bot funcionar!

Há, como sempre, melhorias que quero fazer no bot. No momento, ele não verifica se há um pedido de pull request pendente antes de fazer outro. Ainda é difícil dizer a mudança exata que aconteceu na fonte original, e é possível não perceber uma mudança de tradução necessária. Mas eu confio nos mantenedores que escolhemos para resolver esses problemas, e o bot é open source se alguém quiser me ajudar a fazer essas melhorias!

Agradecimentos

Por fim, gostaria de estender minha gratidão às seguintes pessoas e grupos:

• Todos os mantenedores e contribuidores que estão ajudando a traduzir o React para mais de trinta idiomas.
• O Grupo de Usuários do Vue.js Japão por ter a ideia de ter traduções gerenciadas por um bot e, especialmente, a Hanatani Takuma por nos ajudar a entender sua abordagem e ajudar a manter a tradução em japonês.
• Soichiro Miki por muitas contribuições e comentários heio de idéias sobre o processo geral de tradução, bem como por manter a tradução japonesa.
• Eric Nakagawa por gerenciar nosso processo de tradução anterior.
• Brian Vaughn por configurar a página de idiomas e gerenciar todos os subdomínios.

E finalmente, obrigada a Dan Abramov por me dar esta oportunidade e ser um grande mentor ao longo do caminho.

O Que São Hooks?

Hooks lhe permite utilizar estado e outras funcionalidades do React sem a necessidade de escrever uma classe. Assim como, você também pode criar o seus próprios Hooks para compartilhar e reutilizar sua lógica com estado entre componentes.

Se você nunca ouviu falar sobre Hooks antes, talvez você ache estes tópicos interessantes:

• Introduzindo Hooks explica porque nós estamos adicionando Hooks ao React.
• Hooks de Forma Resumida é uma visão geral sobre o Hooks.
• Criando Seus Próprios Hooks demonstra como reutilizar de código utilizando Hooks personalizados.
• O Sentido do React Hooks explora as novas possibilidades com Hooks.
• useHooks.com apresenta Hooks mantidos pela comunidade e suas implementações.

Você não precisa aprender Hooks agora. Hooks não quebra aplicações existentes, e nós não temos planos de remover o uso de classes do React. O Hooks FAQ descreve à adoção gradual da estratégia.

Sem Grandes Reescritas

Não recomendamos que você reescreva suas aplicações existentes, apenas para utilizar Hooks de uma hora para outra. Pelo contrário, tente utilizar Hooks em alguns de seus novos componentes, e deixe-nos saber o que você acha. Desenvolver utlizando Hooks, funcionará lado a lado ao código já existente qual faz uso de classes.

Posso usar Hooks hoje?

Sim! Iniciando com a versão 16.8.0, o React inclui a versão estável da implementação do React Hooks para:

• React DOM
• React DOM Servidor (React DOM Server)
• Renderizador de Teste React (React Test Renderer)
• Renderizador Superficial React (React Shallow Renderer)

Observe que para utilizar Hooks, todos os pacotes do React precisam estar na versão 16.8.0 ou superior. Hooks não irão funcionar se você esquecer de atualizar, por exemplo, o React DOM.

O React Native terá suporte ao Hooks na versão 0.59.

Suporte de Ferramentas

React Hooks agora são suportados pelo React DevTools. Assim como, as últimas definições de Flow e TypeScript do React. Nós recomendamos fortemente a utilização da nova regra lint, chamada: eslint-plugin-react-hooks, para a aplicação das melhores práticas de codificação com Hooks. Em breve, ela será incluída ao Create React App por padrão.

O Que Vem a Seguir

Nós descrevemos nossos planos para os próximos meses na recente publicação do Roteiro React.

Observe que React Hooks ainda não cobrem todos os casos de uso de classes, mas eles estão bem próximos. Atualmente, apenas os métodos que não possuem API de Hooks equivalentes são getSnapshotBeforeUpdate() e componentDidCatch(), estes ciclos de vida são relativamentes incomuns. Se você quiser, você deve conseguir utilizar Hooks em grande parte do novo código qual você está escrevendo.

Mesmo enquanto Hooks estavam em sua versão alpha, a comunidade React criou muitos exemplos e indicações interessantes usando Hooks, seja para animações, formulários, subscriptions, integração com outras bibliotecas e assim por diante. Nós estamos entusiasmados com Hooks, porque eles tornam a reutilização de código mais fácil, ajudando você a escrever seus componentes de forma simples e criando grandes experiências de usuário. Não podemos esperar para ver o que você irá criar em seguida!

Testando os Hooks

Nós adicionamos uma nova API nesta versão, chamada ReactTestUtils.act(). Ela garante que o comportamento de seus testes, correspondam de forma mais semelhante com o que acontece no navegador. Nós recomendamos encapsular quaquer código de renderização e execução de atualizações ao seu componente, dentro das chamadas aos métodos act(). Bibliotecas de teste, do mesmo modo, podem encapsular suas APIs com o método (por exemplo: utilitários do react-testing-library, como render e fireEvent, fazem isto).

Por exemplo, o exemplo de contador desta página pode ser testado assim:

import React from 'react';
import ReactDOM from 'react-dom';
import { act } from 'react-dom/test-utils';import Counter from './Counter';

let container;

beforeEach(() => {
  container = document.createElement('div');
  document.body.appendChild(container);
});

afterEach(() => {
  document.body.removeChild(container);
  container = null;
});

it('can render and update a counter', () => {
  // Testa primeira renderização e resultado
  act(() => {    ReactDOM.render(<Counter />, container);  });  const button = container.querySelector('button');
  const label = container.querySelector('p');
  expect(label.textContent).toBe('Você clicou 0 vezes');
  expect(document.title).toBe('Você clicou 0 vezes');

  // Testa segunda renderização e resultado
  act(() => {    button.dispatchEvent(new MouseEvent('click', {bubbles: true}));  });  expect(label.textContent).toBe('Você clicou 1 vezes');
  expect(document.title).toBe('Você clicou 1 vezes');
});

As chamadas ao método act() também irão disparar os efeitos dentro delas.

Se você precisa testar um Hook customizado, você pode fazer isso criando um componente em seu teste e utilizar seu Hook a partir dele. Assim, você pode testar o componente qual você escreveu.

Para reduzir a repetição, nós recomendamos utilizar a react-testing-library, qual é projetada para incentivar a escrita de testes, que utilizam de seus componentes como o usuário final utiliza.

Agradecimento

Nós gostaríamos de agradecer todos aqueles que comentaram no Hooks RFC, por terem compartilhado suas opiniões. Nós lemos todos os seus comentários e fizemos alguns ajustes finais nas APIs baseando-se neles.

Instalação

React

O React v16.8.0 está disponível no registro do npm.

Para instalar o React 16 com o Yarn, execute:

yarn add react@^16.8.0 react-dom@^16.8.0

Para instalar o React 16 com o npm, execute:

npm install --save react@^16.8.0 react-dom@^16.8.0

Nós também fornecemos compilações UMD do React via CDN:

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Consulte a documentação para instruções de instalações detalhadas.

Extensão ESLint para o React Hooks

Observação

Como mencionado acima, nós recomendamos severamente o uso da regra do eslint-plugin-react-hooks.

Se você está usando o Create React App, ao invéz da configuração manual do ESLint, você pode aguardar pela próxima versão do react-scrips, qual será lançada em breve e irá incluir esta regra.

Assumindo que você já possui o ESLint instalado, excute:

# npm
npm install eslint-plugin-react-hooks --save-dev

# yarn
yarn add eslint-plugin-react-hooks --dev

Então adicione em suas confugações do ESLint:

{
  "plugins": [
    // ...
    "react-hooks"
  ],
  "rules": {
    // ...
    "react-hooks/rules-of-hooks": "error"
  }
}

Histórico de Mudanças

React

• Adiciona Hooks — uma forma de utilizar estado e outras funcionalidades do React sem escrever uma classe. (@acdlite et al. em #13968)
• Aperfeiçoamento da API de inicialização lenta (lazy initialization) do Hook useReducer. (@acdlite em #14723)

React DOM

• Evita renderização de valores identicos nos Hooks useState e useReducer. (@acdlite em #14569)
• Não compare o primeiro argumento passado aos Hooks useEffect/useMemo/useCallback. (@acdlite em #14594)
• Utilização do algortimo Object.is para comparação dos valores de useState e useReducer. (@Jessidhia em #14752)
• Suporte síncrono aos thenables passados para React.lazy(). (@gaearon em #14626)
• Renderiza os componentes com Hooks duas vezes no Modo Estrito (Strict Mode) - apenas DEV, para combinar o comportamento de classe. (@gaearon em #14654)
• Aviso sobre a incompatibilidade do Hooks quanto ao desenvolvimento. (@threepointone em #14585 e @acdlite em #14591)
• As funções de limpeza de resultados devem retornar undefined ou uma função. Todos os outros valores, incluindo null, não são permitidos. @acdlite em #14119

Renderizador de Teste React

• Suporte para Hooks no renderizador superficial (Shallow Renderer). (@trueadm em #14567)
• Correção do estado do shouldComponentUpdate junto ao getDerivedStateFromProps ao renderizador superficial (Shallow Renderer). (@chenesan em #14613)
• Adiciona ReactTestRenderer.act() e ReactTestUtils.act() para atualizações em lote a fim de que testes sejam executados de forma mais semelhante ao comportamento real. (@threepointone em #14744)

Extensão ESLint: React Hooks

• Lançamento inicial. (@calebmer em #13968)
• Correção do relatório após encontrar ciclo. (@calebmer e @Yurickh em #14661)
• Não considere lançamento de exceção como uma violação de regra. (@sophiebits em #14040)

Histórico de mudanças do Hooks desde a versão alpha

O histórico de mudanças acima contém todas as mudanças notáveis, desde a nossa última versão estável (16.7.0). Assim como, todos o nossos lançamentos secundários, não interrompe a compatibilidade com as versões anteriores.

Se você está utilizando Hooks da versão alpha do React, observe que esta versão contêm algumas pequenas mudanças, que causa instabilidade ao Hooks. Nós não recomendamos a dependência da versão alpha em código de produção. Nós publicamos versões alpha para realizar mudanças com base na opinião da comunidade, antes da versão estável da API.

Aqui estão todas as mudanças radicais do Hooks, quais foram feitas desde a primeira versão alpha:

• Remove useMutationEffect. (@sophiebits em #14336)
• Renomeia useImperativeMethods para useImperativeHandle. (@threepointone em #14565)
• Evita renderização de valores idênticos nos Hooks useState e useReducer. (@acdlite em #14569)
• Não compare o primeiro argumento passado aos Hooks useEffect/useMemo/useCallback. (@acdlite em #14594)
• Utilização do algortimo Object.is para comparação dos valores de useState e useReducer. (@Jessidhia em #14752)
• Renderiza os componentes com Hooks duas vezes no Modo Estrito (Strict Mode) - apenas DEV. (@gaearon em #14654)
• Aperfeiçoamento da API de inicialização lenta (lazy initialization) do Hook useReducer. (@acdlite em #14723)