Por mais de um ano, a equipe do React tem trabalhado para implementar a renderização assíncrona. No mês passado, durante sua palestra no JSConf na Islândia, Dan revelou algumas das novas possibilidades excitantes que a renderização assíncrona desbloqueia. Agora, gostaríamos de compartilhar com você algumas das lições que aprendemos ao trabalhar nesses recursos e algumas receitas para ajudar a preparar seus componentes para renderização assíncrona quando ela for lançada.
\nUma das maiores lições que aprendemos é que alguns dos nossos ciclos de vida de componentes legados tendem a incentivar práticas de codificação inseguras. Eles são:
\ncomponentWillMountcomponentWillReceivePropscomponentWillUpdateEstes métodos de ciclo de vida têm sido muitas vezes incompreendidos e sutilmente usurpados; Além disso, prevemos que o seu potencial uso indevido pode ser mais problemático com a renderização assíncrona. Devido a isso, nós estaremos adicionando um prefixo “UNSAFE_” para esses ciclos de vida em uma próxima versão. (Aqui, “inseguro” não refere-se à segurança, mas sim que códigos utilizando esses ciclos de vida terão mais chances de ter bugs em versões futuras do React, especialmente quando a renderização assíncrona estiver habilitada.)
\nReact segue o controle de versão semântica, portanto, essa alteração será gradual. Nosso plano atual é:
\nUNSAFE_componentWillMount, UNSAFE_componentWillReceiveProps, e UNSAFE_componentWillUpdate. (Tanto os nomes de ciclos de vida antigos quanto os novos pseudônimos funcionarão nesta versão.)componentWillMount, componentWillReceiveProps, e componentWillUpdate. (Tanto os nomes de ciclos de vida antigos e os novos pseudônimos funcionarão nesta versão, mas os nomes antigos registrarão um aviso em modo de desenvolvimento.)componentWillMount, componentWillReceiveProps, e componentWillUpdate . (Apenas os novos nomes de ciclo de vida “UNSAFE_” funcionarão a partir deste ponto para a frente.)Observe que, se você for um desenvolvedor de aplicativos React, não precisará fazer nada sobre os métodos legados por enquanto. O objetivo principal da próxima versão 16.3 é permitir que os mantenedores do projeto de código aberto atualizem suas bibliotecas antes de quaisquer avisos de substituição. Esses avisos não serão ativados até uma versão 16.x futura.
\nMantemos mais de 50.000 componentes do React no Facebook, e não planejamos reescrevê-los imediatamente. Entendemos que as migrações levam tempo. Tomaremos o caminho de migração gradual junto com todos na comunidade React.
\nSe você não tiver tempo para migrar ou testar esses componentes, recomendamos executar um script “codemod” que os renomeia automaticamente:
\ncd seu_projeto\nnpx react-codemod rename-unsafe-lifecyclesSaiba mais sobre este codemod no post da versão 16.9.0.
\nSe gostaria de começar a usar as novas APIs de componentes introduzidas no React 16.3 (ou se você for um mantenedor procurando atualizar sua biblioteca com antecedência) aqui estão alguns exemplos que esperamos que o ajudem a começar a pensar em componentes um pouco diferente. Ao longo do tempo, planejamos adicionar “receitas” adicionais à nossa documentação que mostram como executar tarefas comuns de uma forma que evite os ciclos de vida problemáticos.
\nAntes de começarmos, aqui está uma rápida visão geral das alterações de ciclo de vida planejadas para a versão 16.3:
\nUNSAFE_componentWillMount, UNSAFE_componentWillReceiveProps, e UNSAFE_componentWillUpdate. (Os nomes de ciclo de vida antigos e os novos pseudônimos serão suportados.)getDerivedStateFromProps e getSnapshotBeforeUpdate.getDerivedStateFromProps class Example extends React.Component {\n static getDerivedStateFromProps(props, state) {\n // ...\n }\n}O novo ciclo de vida estático getDerivedStateFromProps é invocado depois que um componente é instanciado, bem como antes de ser renderizado novamente. Ele pode retornar um objeto para atualizar o state, ou null para indicar que as novas props não exigem quaisquer atualizações de state.
Juntamente com componentDidUpdate, esse novo ciclo de vida deve abranger todos os casos de uso para o legado componentWillReceiveProps.
\n\nNota:
\nTanto o antigo método
\ncomponentWillReceivePropse quanto o novogetDerivedStateFromPropsadicionam uma complexidade significativa para os componentes. Isso muitas vezes leva a bugs. Considere alternativas mais simples aostatederivado para tornar os componentes previsíveis e sustentáveis.
getSnapshotBeforeUpdate class Example extends React.Component {\n getSnapshotBeforeUpdate(prevProps, prevState) {\n // ...\n }\n}O novo ciclo de vida getSnapshotBeforeUpdate é chamado logo antes que as mutações sejam feitas (por exemplo, antes que o DOM seja atualizado). O valor de retorno para este ciclo de vida será passado como o terceiro parâmetro para componentDidUpdate. (Esse ciclo de vida não é freqüentemente necessário, mas pode ser útil em casos como preservar manualmente a posição de rolagem durante as renderizações.)
Juntamente com componentDidUpdate, esse novo ciclo de vida deve abranger todos os casos de uso para o legado componentWillUpdate.
Você pode encontrar as assinaturas de tipo neste gist.
\nVamos ver exemplos de como ambos os ciclos de vida podem ser usados abaixo.
\nstate baseado em props\n\nNota
\nPara brevidade, os exemplos abaixo são escritos usando a classe experimental de transformação de propriedades, mas as mesmas estratégias de migração se aplicam sem ela.
\n
Este exemplo mostra um componente com a chamada de setState dentro de componentWillMount:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {};\n\n componentWillMount() { this.setState({ currentColor: this.props.defaultColor, palette: 'rgb', }); }}A refatoração mais simples para este tipo de componente é mover a inicialização do state para o construtor ou para um inicializador de propriedade, assim:\n
// After\nclass ExampleComponent extends React.Component {\n state = { currentColor: this.props.defaultColor, palette: 'rgb', };}Aqui está um exemplo de um componente que usa componentWillMount para buscar dados externos:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n componentWillMount() { this._asyncRequest = loadMyAsyncData().then( externalData => { this._asyncRequest = null; this.setState({externalData}); } ); }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n}O código acima é problemático para a renderização do servidor (onde os dados externos não serão usados) e o próximo modo de renderização assíncrona (onde a solicitação pode ser iniciada várias vezes).
\nO caminho de atualização recomendado para a maioria dos casos de uso é mover os dados-buscados para componentDidMount:\n
// After\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n componentDidMount() { this._asyncRequest = loadMyAsyncData().then( externalData => { this._asyncRequest = null; this.setState({externalData}); } ); }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n}Há um equívoco comum que buscando os dados no componentWillMount permitirá que você evite o primeiro estado de renderização vazio. Na prática, isso nunca foi verdade porque o React sempre executa o render imediatamente após o componentWillMount. Se os dados não estiverem disponíveis no momento em que componentWillMount é acionado, o primeiro render ainda mostrará um estado de carregamento, independentemente de onde você iniciar a busca. É por isso que mover a busca para componentWillMount não tem nenhum efeito perceptível na grande maioria dos casos.
\n\nNota
\nAlguns casos de uso avançados (por exemplo, bibliotecas como Relay) podem querer experimentar de forma ansiosa os dados assíncronos pré-buscados. Um exemplo de como isso pode ser feito está disponível aqui.
\nA longo prazo, a forma canônica de buscar dados em componentes do React provavelmente será baseada na API de “suspense” introduzida no JSConf Islândia. Ambas as soluções para buscar dados dados simples buscando e bibliotecas como Apollo e Relay serão capazes de utilizá-la por baixo dos panos. É significativamente menos verboso do que qualquer uma das soluções acima, mas não será finalizado em tempo para a versão 16.3.
\nAo oferecer suporte a renderização do servidor, é atualmente necessário fornecer os dados sincronicamente –
\ncomponentWillMountfoi freqüentemente usado para essa finalidade, mas o construtor pode ser usado como uma substituição. As próximas APIs de suspense farão com que os dados assíncronos sejam obtidos de forma limpa para renderização de cliente e servidor.
Aqui está um exemplo de um componente que assina um dispatcher externo de eventos ao montar-se:\n
// Before\nclass ExampleComponent extends React.Component {\n componentWillMount() { this.setState({ subscribedValue: this.props.dataSource.value, }); // This is not safe; it can leak! this.props.dataSource.subscribe( this.handleSubscriptionChange ); }\n componentWillUnmount() {\n this.props.dataSource.unsubscribe(\n this.handleSubscriptionChange\n );\n }\n\n handleSubscriptionChange = dataSource => {\n this.setState({\n subscribedValue: dataSource.value,\n });\n };\n}Infelizmente, isto pode causar vazamentos de memória para renderização do servidor (onde componentWillUnmount nunca será chamado) e em renderização assíncrona (onde a renderização pode ser interrompida antes de ser concluída, fazendo com que componentWillUnmount não seja chamado).
As pessoas geralmente assumem que componentWillMount e componentWillUnmount estão sempre emparelhados mas isto não é garantido. Somente uma vez que componentDidMount for chamado, o React garante que o componentWillUnmount será chamado para a limpeza.
Por esse motivo, a maneira recomendada para adicionar ouvintes/inscrições é usar o ciclo de vida componentDidMount:\n
// After\nclass ExampleComponent extends React.Component {\n state = { subscribedValue: this.props.dataSource.value, }; componentDidMount() { // Event listeners are only safe to add after mount, // So they won't leak if mount is interrupted or errors. this.props.dataSource.subscribe( this.handleSubscriptionChange ); // External values could change between render and mount, // In some cases it may be important to handle this case. if ( this.state.subscribedValue !== this.props.dataSource.value ) { this.setState({ subscribedValue: this.props.dataSource.value, }); } }\n componentWillUnmount() {\n this.props.dataSource.unsubscribe(\n this.handleSubscriptionChange\n );\n }\n\n handleSubscriptionChange = dataSource => {\n this.setState({\n subscribedValue: dataSource.value,\n });\n };\n}Às vezes, é importante atualizar as inscrições às alterações de propriedades. Se você estiver utilizando uma biblioteca como o Redux ou Mobx, o componente de contêiner da da biblioteca deve lidar com isso para você. Para autores de aplicações, criamos uma pequena biblioteca, create-subscription, para ajudar com isto. Vamos publicá-la junto com o React 16.3.
Em vez de passar uma prop dataSource assinada como fizemos no exemplo acima, poderíamos usar o create-subscription para passar o valor subscrito:
import {createSubscription} from 'create-subscription';\n\nconst Subscription = createSubscription({\n getCurrentValue(sourceProp) {\n // Return the current value of the subscription (sourceProp).\n return sourceProp.value;\n },\n\n subscribe(sourceProp, callback) {\n function handleSubscriptionChange() {\n callback(sourceProp.value);\n }\n\n // Subscribe (e.g. add an event listener) to the subscription (sourceProp).\n // Call callback(newValue) whenever a subscription changes.\n sourceProp.subscribe(handleSubscriptionChange);\n\n // Return an unsubscribe method.\n return function unsubscribe() {\n sourceProp.unsubscribe(handleSubscriptionChange);\n };\n },\n});\n\n// Rather than passing the subscribable source to our ExampleComponent,\n// We could just pass the subscribed value directly:\n<Subscription source={dataSource}>\n {value => <ExampleComponent subscribedValue={value} />}\n</Subscription>;\n\nNota
\nBibliotecas como Relay/Apollo devem gerenciar inscrições manualmente com as mesmas técnicas que
\ncreate-subscriptionutilizam por baixo dos panos (como referenciado aqui) de uma forma que é mais otimizado para o uso da biblioteca.
state baseado em props \n\nNota:
\nTanto o antigo método
\ncomponentWillReceivePropse o novogetDerivedStateFromPropsadicionam uma complexidade significativa para componentes. Isso muitas vezes levam a bugs. Considere alternativas mais simples ao state derivado para tornar os componentes previsíveis e sustentáveis.
Aqui está um exemplo de um componente que utiliza o ciclo de vida componentWillReceiveProps legado para atualizar o state baseado em um novo valor de uma props:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {\n isScrollingDown: false,\n };\n\n componentWillReceiveProps(nextProps) { if (this.props.currentRow !== nextProps.currentRow) { this.setState({ isScrollingDown: nextProps.currentRow > this.props.currentRow, }); } }}Embora o código acima não seja problemático em si, o ciclo de vida componentWillReceiveProps geralmente é utilizado de forma abusiva fazendo com que apresentem problemas. Devido a isso, o método será depreciado.
A partir da versão 16.3, a maneira recomendada de atualizar o state em resposta a mudanças de props é com o novo ciclo de vida static getDerivedStateFromProps. Ele é chamado quando o componente é criado e todas as vezes que o mesmo for renderizado novamente quando houver mudanças de props ou state:\n
// After\nclass ExampleComponent extends React.Component {\n // Initialize state in constructor,\n // Or with a property initializer.\n state = { isScrollingDown: false, lastRow: null, };\n static getDerivedStateFromProps(props, state) { if (props.currentRow !== state.lastRow) { return { isScrollingDown: props.currentRow > state.lastRow, lastRow: props.currentRow, }; }\n // Return null to indicate no change to state.\n return null;\n }\n}Você pode notar no exemplo acima que props.currentRow é espelhado no state (como state.lastRow). Isso permite getDerivedStateFromProps acessar o valor anterior de props da mesma maneira como é feito em componentWillReceiveProps.
Você pode se perguntar por que nós não apenas passamos as props anteriores como parâmetro para o getDerivedStateFromProps. Nós consideramos essa opção ao projetar a API, mas finalmente decidimos ir contra ela por dois motivos:
prevProps seria nulo na primeira vez que getDerivedStateFromProps fosse chamado (após ser instanciado), requerendo adicionar uma checagem if-not-null a qualquer momento em que prevProps fosse acessado.props em memória.)\n\nNota
\nSe você está escrevendo um componente compartilhado, o polyfill
\nreact-lifecycles-compatpermite que o novo ciclo de vidagetDerivedStateFromPropsseja usado em versões mais antigas do React também. Saiba mais sobre como usá-lo abaixo.
Aqui está um exemplo de um componente que chama uma função externa quando seu state interno é alterado:\n
// Before\nclass ExampleComponent extends React.Component {\n componentWillUpdate(nextProps, nextState) { if ( this.state.someStatefulValue !== nextState.someStatefulValue ) { nextProps.onChange(nextState.someStatefulValue); } }}Às vezes, as pessoas usam componentWillUpdate com medo de que quando componentDidUpdate for disparado, isso seja “tarde demais” para atualizar o state de outros componentes. Este não é o caso. O React garante que qualquer chamada ao setState que esteja ocorrendo durante componentDidMount e componentDidUpdate sejam liberadas antes que o usuário veja a UI atualizada. Em geral, é melhor evitar atualizações em cascatas como esta, mas em alguns casos elas podem ser necessárias (por exemplo, se você precisa posicionar uma tooltip medir o elemento renderizado no DOM).
De qualquer maneira, não é seguro fazer o uso de componentWillUpdate para este propósito em modo assíncrono, porque o retorno de uma chamada externa pode ser executada múltiplas em uma única atualização. Em vez disso, o ciclo de vida componentDidUpdate deve ser utilizado pois é gerantido que seja invocado uma única vez por atualização:\n
// After\nclass ExampleComponent extends React.Component {\n componentDidUpdate(prevProps, prevState) { if ( this.state.someStatefulValue !== prevState.someStatefulValue ) { this.props.onChange(this.state.someStatefulValue); } }}Similar ao exemplo acima, às vezes os componentes tem efeitos colaterais quando ocorrem mudanças de props.
// Before\nclass ExampleComponent extends React.Component {\n componentWillReceiveProps(nextProps) { if (this.props.isVisible !== nextProps.isVisible) { logVisibleChange(nextProps.isVisible); } }}Assim como o componentWillUpdate, o componentWillReceiveProps pode ser chamado várias vezes para uma única atualização. Por esta razão, é importante evitar colocar efeitos colaterais neste método. Em vez disso, componentDidUpdate deve ser usado uma vez que é garantido que seja invocado uma única vez por atualização:
// After\nclass ExampleComponent extends React.Component {\n componentDidUpdate(prevProps, prevState) { if (this.props.isVisible !== prevProps.isVisible) { logVisibleChange(this.props.isVisible); } }}props mudarem Aqui está um exemplo de um componente que busca dados externos com base em valores de props:\n
// Before\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n componentDidMount() {\n this._loadAsyncData(this.props.id);\n }\n\n componentWillReceiveProps(nextProps) { if (nextProps.id !== this.props.id) { this.setState({externalData: null}); this._loadAsyncData(nextProps.id); } }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n\n _loadAsyncData(id) {\n this._asyncRequest = loadMyAsyncData(id).then(\n externalData => {\n this._asyncRequest = null;\n this.setState({externalData});\n }\n );\n }\n}A solução recomendado para este componente é mover as atualizações de dados para componentDidUpdate. Você também pode usar o novo ciclo de vida getDerivedStateFromProps para limpar dados obsoletos antes de renderizar as novas props:
// After\nclass ExampleComponent extends React.Component {\n state = {\n externalData: null,\n };\n\n static getDerivedStateFromProps(props, state) { // Store prevId in state so we can compare when props change. // Clear out previously-loaded data (so we don't render stale stuff). if (props.id !== state.prevId) { return { externalData: null, prevId: props.id, }; } // No state update necessary return null; }\n componentDidMount() {\n this._loadAsyncData(this.props.id);\n }\n\n componentDidUpdate(prevProps, prevState) { if (this.state.externalData === null) { this._loadAsyncData(this.props.id); } }\n componentWillUnmount() {\n if (this._asyncRequest) {\n this._asyncRequest.cancel();\n }\n }\n\n render() {\n if (this.state.externalData === null) {\n // Render loading state ...\n } else {\n // Render real UI ...\n }\n }\n\n _loadAsyncData(id) {\n this._asyncRequest = loadMyAsyncData(id).then(\n externalData => {\n this._asyncRequest = null;\n this.setState({externalData});\n }\n );\n }\n}\n\nNota
\nSe você estiver usando uma biblioteca HTTP que ofereça suporte ao cancelamento, como axios, é simples cancelar uma solicitação em andamento ao desmontar o componente. Para Promises nativas, você pode usar uma abordagem como a mostrada aqui.
\n
Aqui está um exemplo de um componente que lê uma propriedade do DOM antes de uma atualização a fim de manter a posição de rolagem dentro de uma lista:\n
class ScrollingList extends React.Component {\n listRef = null;\n previousScrollOffset = null;\n\n componentWillUpdate(nextProps, nextState) { // Are we adding new items to the list? // Capture the scroll position so we can adjust scroll later. if (this.props.list.length < nextProps.list.length) { this.previousScrollOffset = this.listRef.scrollHeight - this.listRef.scrollTop; } }\n componentDidUpdate(prevProps, prevState) { // If previousScrollOffset is set, we've just added new items. // Adjust scroll so these new items don't push the old ones out of view. if (this.previousScrollOffset !== null) { this.listRef.scrollTop = this.listRef.scrollHeight - this.previousScrollOffset; this.previousScrollOffset = null; } }\n render() {\n return (\n <div ref={this.setListRef}>\n {/* ...contents... */}\n </div>\n );\n }\n\n setListRef = ref => {\n this.listRef = ref;\n };\n}No exemplo acima, componentWillUpdate é usado para ler a propriedade DOM. No entanto, com renderização assíncrona, pode haver atrasos entre os ciclos de vida de fase “render” (como componentWillUpdate e render) e os ciclos de vida de fase “commit” (como componentDidUpdate). Se o usuário fizer algo como redimensionar a janela durante esse tempo, o valor de scrollHeight lido de componentWillUpdate será obsoleto.
A solução para esse problema é usar o novo ciclo de vida de fase “commit”, getSnapshotBeforeUpdate. Este método é chamado imediatamente antes de mutações serem realizadas (por exemplo, antes do DOM ser atualizado). Ele pode retornar um valor para o React passar como um parâmetro para componentDidUpdate, que é chamado imediatamente após as mutações.
Os dois ciclos de vida podem ser usados juntos assim:
\nclass ScrollingList extends React.Component {\n listRef = null;\n\n getSnapshotBeforeUpdate(prevProps, prevState) { // Are we adding new items to the list? // Capture the scroll position so we can adjust scroll later. if (prevProps.list.length < this.props.list.length) { return ( this.listRef.scrollHeight - this.listRef.scrollTop ); } return null; }\n componentDidUpdate(prevProps, prevState, snapshot) { // If we have a snapshot value, we've just added new items. // Adjust scroll so these new items don't push the old ones out of view. // (snapshot here is the value returned from getSnapshotBeforeUpdate) if (snapshot !== null) { this.listRef.scrollTop = this.listRef.scrollHeight - snapshot; } }\n\n render() {\n return (\n <div ref={this.setListRef}>\n {/* ...contents... */}\n </div>\n );\n }\n\n setListRef = ref => {\n this.listRef = ref;\n };\n}\n\nNota
\nSe você estiver escrevendo um componente compartilhado, o polyfill
\nreact-lifecycles-compatpermite que o novo ciclo de vidagetSnapshotBeforeUpdateseja usado com versões mais antigas do React também. Saiba mais sobre como usá-lo abaixo.
Enquanto tentamos cobrir os casos de uso mais comuns nesta publicação, reconhecemos que podemos ter perdido alguns deles. Se você estiver usando componentWillMount, componentWillUpdate, ou componentWillReceiveProps de maneiras não cobertas por esta postagem e não tem certeza de como migrar esses ciclos de vida legados, por favor envie-nos uma nova issue referente a nossa documentação com o seu código de exemplo e o máximo de informações que puder fornecer. Atualizaremos este documento com novos padrões alternativos à medida que eles aparecerem.
Os mantenedores de código aberto podem estar se perguntando o que essas alterações significam para componentes compartilhados. Se você implementar as sugestões acima, o que acontece com componentes que dependem do novo ciclo de vida estático getDerivedStateFromProps? Você também terá que liberar uma nova versão principal e quebrar a compatibilidade com o React 16.2 e versões anteriores?
Felizmente, não!
\nQuando o React 16.3 for publicado, também publicaremos um novo pacote npm, react-lifecycles-compat. Este pacote contém polyfills de componentes para que os novos ciclos de vida getDerivedStateFromProps e getSnapshotBeforeUpdate funcionem também com versões mais antigas do React (0.14.9+).
Para usar esse polyfill, primeiro adicione-o como uma dependência à sua biblioteca:
\n# Yarn\nyarn add react-lifecycles-compat\n\n# NPM\nnpm install react-lifecycles-compat --saveEm seguida, atualize seus componentes para utilizarem os novos ciclos de vida (como descrito acima).
\nPor fim, utilize o polyfill para tornar seu componente compatível com versões anteriores do React:\n
import React from 'react';\nimport {polyfill} from 'react-lifecycles-compat';\nclass ExampleComponent extends React.Component {\n static getDerivedStateFromProps(props, state) { // Your state update logic here ...\n }\n}\n\n// Polyfill your component to work with older versions of React:\npolyfill(ExampleComponent);\nexport default ExampleComponent;