Hoje, estamos publicando o primeiro candidato à lançamento do React 17. Já se passaram dois anos e meio desde o principal lançamento anterior do React, que é muito tempo, mesmo para os nossos padrões! Nesta postagem do blog, descreveremos a função desta versão principal, quais mudanças você pode esperar dela e como você pode experimentar esta versão.
\nA 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.
\nEstamos 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.
\nEm 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.
\nNos ú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.
\nIsso 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.
\nPortanto, queríamos oferecer outra opção.
\nReact 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.
\nEstamos 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.
\nIsso 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.
\nPara 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.
\nPreparamos 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.
\n\n\nNota
\nAdiamos 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.
\n
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.
\nNos componentes React, você geralmente escreve manipuladores de eventos (event handler) inline:
\n<button onClick={handleClick}>O DOM vanilla equivalente a este código é semelhante à:
\nmyButton.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.
\nSe 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.
\nNo 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');\nReactDOM.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.
\n
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.
\nEssa 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.
\n\n\nNota
\nVocê 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.
\n
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.
\nPor 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() {\n // Este manipulador personalizado não receberá mais cliques\n // dos componentes React que chamaram e.stopPropagation()\n});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() {\n // Agora este event handlers usa a fase de captura\n // então ele recebe *todas* os eventos de clique abaixo!\n}, { 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 .
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.
\nFizemos algumas alterações menores relacionadas ao sistema de eventos:
\nonScroll não propaga mais a fim de previnir algumas confusões comuns.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.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.
\n\n\nNota
\nEmbora o React 17 tenha mudado de
\nfocusparafocusinpor debaixo dos panos para o eventoonFocus, note que isso não afetou o comportamento de propagação. No React, o eventoonFocussempre 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.
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:
\nfunction handleChange(e) {\n setData(data => ({\n ...data,\n // Isso trava no React 16 e anteriores:\n text: e.target.value\n }));\n}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.
\nEsta é 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.
Estamos tornando o tempo da função de limpeza useEffect mais consistente.
useEffect (() => {\n // Este é o próprio Effect.\n 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.
\nIsso 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.
\n\nNota
\nVocê deve estar se perguntando se isso significa que agora você não conseguirá corrigir avisos sobre
\nsetStateem componentes não montados. Não se preocupe — o React verifica especificamente este caso e não dispara avisos desetStateno 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.
\nNó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:
\nuseEffect(() => {\n someRef.current.someSetupMethod();\n return () => {\n someRef.current.someCleanupMethod();\n };\n});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(() => {\n const instance = someRef.current;\n instance.someSetupMethod();\n return () => {\n instance.someCleanupMethod();\n };\n});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.
No React 16 e anteriores, retornar undefined sempre foi um erro:
function Button() {\n return; // Erro: nada foi retornado da renderização\n}Isso ocorre em parte porque é fácil retornar undefined involuntariamente:
function Button() {\n // Esquecemos de escrever return, então este componente retorna indefinido.\n // React mostra isso como um erro em vez de ignorá-lo.\n <button />;\n}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(() => {\n // Esquecemos de escrever return, então este componente retorna indefinido.\n // React 17 mostra isso como um erro em vez de ignorá-lo.\n <button />;\n});\n\nlet Button = memo(() => {\n // Esquecemos de escrever return, então este componente retorna indefinido.\n // React 17 mostra isso como um erro em vez de ignorá-lo.\n <button />;\n});Para os casos em que você não deseja renderizar nada intencionalmente, retorne null.
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.
\nNo 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.
\nA 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.
\nSe 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.
\nA 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.
\nPor 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.
\nNo 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.
\nIsso 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.
\nAlé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.
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.
\nPara instalar o React 17 RC com npm, execute:
\nnpm install react@17.0.0-rc.3 react-dom@17.0.0-rc.3Para instalar o React 17 RC com Yarn, execute:
\nyarn add react@17.0.0-rc.3 react-dom@17.0.0-rc.3Também fornecemos compilações UMD do React por meio de um CDN:
\n<script crossorigin src=\"https://unpkg.com/react@17.0.0-rc.3/umd/react.production.min.js\"></script>\n<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.
\nreact/jsx-runtime e react/jsx-dev-runtime para que a nova transformação JSX. (@lunaruan em #18299)displayName no contexto para pilhas melhoradas. (@eps1lon em #18224)'use strict' vaze nos pacotes UMD. (@koba04 em #19614)fb.me para redirecionamentos. (@cylim em #19598)document. (@trueadm em #18195 e outros)useEffect de forma assíncrona. (@bvaughn em #17925)focusin e focusout para onFocus e onBlur. (@trueadm em #19186)Capture usem a fase de captura do navegador. (@trueadm em #19221)onScroll. (@gaearon em #19464)forwardRef ou memo retornar undefined. (@gaearon em #19550)console na segunda passagem de renderização do modo DEV de renderização dupla. (@sebmarkbage em #18547)ReactTestUtils.SimulateNative não documentada e confusa. (@gaearon em #13407)ReactDOM.flushSync durante os métodos de ciclo de vida (mas avisar). (@sebmarkbage em #18759)code aos objetos de evento do teclado. (@bl00mber em #18287)disableRemotePlayback para os elementos video. (@tombrowndev em #18619)enterKeyHint para elementos input. (@eps1lon em #18634)valor é fornecido para <Context.Provider>. (@charlie1404 em #19054)memo ou forwardRef retornam undefined. (@bvaughn em #19550)onTouchStart, onTouchMove e onWheel passivos. (@gaearon em #19654)setState pendurado em desenvolvimento dentro de um iframe fechado. (@gaearon em #19220)defaultProps. (@jddxf em #18539)hazouslySetInnerHTML é undefined. (@eps1lon em #18676)require não padrão. (@just-boris em #18632)onBeforeInput relatando um event.type incorreto. (@eps1lon em #19561)event.relatedTarget relatado como undefined no Firefox. (@claytercek em #19607movementX / Y com eventos de captura. (@gaearon em #19672)onSubmit e onReset. (@gaearon em #19333)useCallback consistente com useMemo para o renderizador do servidor. (@alexmckenley em #18783)findByType. (@henryqdineen em #17439)unstable_ antes das APIs experimentais. (@acdlite em #18825)unstable_discreteUpdates e unstable_flushDiscreteUpdates. (@trueadm em #18825)timeoutMs. (@acdlite em #19703)<div hidden /> pré-renderizando em favor de uma API futura diferente. (@acdlite em #18917)unstable_expectedLoadTime no Suspense para a árvores do CPU-bound. (@acdlite em #19936)unstable_useOpaqueIdentifier. (@lunaruan em #17322)unstable_startTransition. (@rickhanlonii em #19696)act em o renderizador de teste não libera mais os fallbacks do Suspense. (@acdlite em #18596)useMutableSource que pode acontecer quandogetSnapshot muda. (@bvaughn em #18297)useMutableSource. (@bvaughn em #18912)