Há alguns dias, escrevemos uma postagem sobre as próximas mudanças em nossos métodos de ciclo de vida legados, incluindo estratégias de migração gradual. No React 16.3.0, estamos adicionando alguns novos métodos de ciclo de vida para ajudar nessa migração. Também estamos introduzindo novas APIs para funcionalidades há tempo solicitadas: uma API de contexto oficial, uma API de referência de encaminhamento e uma API de referência de ergonomia.
\nLeia para saber mais sobre o lançamento.
\nPor muitos anos, o React ofereceu uma API experimental para contexto. Embora fosse uma ferramenta poderosa, seu uso foi desencorajado por causa de problemas inerentes na API, e porque sempre pretendíamos substituir a API experimental por uma melhor.
\nA versão 16.3 introduz uma nova API de contexto que é mais eficiente e suporta tanto verificação de tipo estático quanto atualizações profundas.
\n\n\nNota
\nA antiga API de contexto continuará funcionando para todas as versões do React 16.x, assim você terá tempo para migrar.
\n
Aqui está um exemplo ilustrando como você pode introduzir um “tema” usando a nova API de contexto:\n
const ThemeContext = React.createContext('light');\nclass ThemeProvider extends React.Component {\n state = {theme: 'light'};\n\n render() {\n return (\n <ThemeContext.Provider value={this.state.theme}> {this.props.children} </ThemeContext.Provider> );\n }\n}\n\nclass ThemedButton extends React.Component {\n render() {\n return (\n <ThemeContext.Consumer> {theme => <Button theme={theme} />} </ThemeContext.Consumer> );\n }\n}Saiba mais sobre a nova API de contexto aqui.
\ncreateRef Anteriormente, o React fornecia duas maneiras de gerenciar refs: a legada API de string ref e a API de callback. Embora a API de string ref ter sido a mais conveniente das duas, ela tinha várias desvantagens e assim nossa recomendação oficial era usar a forma de callback.
\nA versão 16.3 adiciona uma nova opção para gerenciar refs que oferecem o conforto de uma string ref sem nenhuma das desvantagens:\n
class MyComponent extends React.Component {\n constructor(props) {\n super(props);\n\n this.inputRef = React.createRef(); }\n\n render() {\n return <input type=\"text\" ref={this.inputRef} />; }\n\n componentDidMount() {\n this.inputRef.current.focus(); }\n}\n\nNota:
\nAs refs de callbacks continuarão sendo suportadas, além da nova API
\ncreateRef.Você não precisa substituir as callback refs em seus componentes. Elas são um pouco mais flexíveis, portanto, elas permanecerão como um recurso avançado.
\n
Saiba mais sobre a nova API createRef aqui.
forwardRef Geralmente, os componentes React são declarativos, mas às vezes é necessário o acesso imperativo às instâncias do componente e aos nós DOM necessários. Isso é comum em casos de uso, como gerenciamento de foco, seleção ou animações. O React fornece refs uma maneira de resolver este problema. No entanto, o encapsulamento de componentes apresenta alguns desafios com as refs.
\nPor exemplo, se você trocar um <button> por um componente <FancyButton>, o atributo ref nele começará a apontar para o componente encapsulando em vez do nó DOM (e seria null para componentes funcionais). Embora isso seja desejável para componentes de “nível de aplicação” como FeedStory ou Comment que precisam ser encapsulados, isso pode ser incômodo para componentes “folha” como FancyButton ou MyTextInput que são tipicamente usados como seus equivalentes do DOM e podem precisar expor seus nós do DOM.
A referência de encaminhamento é um novo recurso de inclusão que permite que alguns componentes ref sejam recebidos, e passem para baixo (em outras palavras, “encaminhá-lo”) para um filho. No exemplo abaixo, FancyButton encaminha seu ref para um button do DOM que renderiza:
const FancyButton = React.forwardRef((props, ref) => ( <button ref={ref} className=\"FancyButton\"> {props.children}\n </button>\n));\n\n// You can now get a ref directly to the DOM button:\nconst ref = React.createRef();\n<FancyButton ref={ref}>Click me!</FancyButton>;Dessa forma, os componentes que usam FancyButton podem obter uma ref ao nó inerente do button do DOM e acessá-lo se necessário for, como se usassem um button do DOM diretamente.
O encaminhamento de ref não está limitado para componentes de “folha” que rederizam nós do DOM. Se você escreve componente de alta-ordem, recomendamos o uso do encaminhamento de referência para passar automaticamente as ref para as instâncias do componente de classe wrapper.
\nSaiba mais sobre a API forwardRef aqui.
\nA API de componente de classe do React existe há anos com poucas mudanças. No entanto, como nós adicionamos suporte a recursos mais avançados (tal como limite de erros e o próximo modo de renderização assíncrona) nós estendemos esta API de maneiras que não foram originalmente projetadas.
\nPor exemplo, com a API atual, é muito fácil bloquear a renderização inicial com lógica não essencial. Em parte, isso ocorre porque há muitas maneiras de realizar uma determinada tarefa, e pode não ser claro qual é a melhor. Observamos que o comportamento de interrupção do tratamento de erros geralmente não é levado em consideração e pode resultar em vazamentos de memória (algo que também afetará o próximo modo de renderização assíncrona). A API do componente de classe atual também complica outros esforços, como o nosso trabalho em prototipar um compilador React.
\nMuitos desses problemas são exacerbados por um subconjunto dos ciclos de vida dos componentes (componentWillMount, componentWillReceiveProps, e componentWillUpdate). Esses também são os ciclos de vida que mais causam confusão na comunidade React. Por essas razões, vamos depreciar esses métodos em favor de alternativas melhores.
Reconhecemos que essa alteração afetará muitos componentes existentes. Por isso, o caminho de migração será o mais gradual possível e fornecerá alternativas de escape. (No Facebook, mantemos mais de 50.000 componentes React. Também dependemos de um ciclo de lançamento gradual!)
\n\n\nNota:
\nOs avisos de deprecação serão ativados com uma versão 16.x futura, mas os ciclos de vida herdados continuarão funcionando até a versão 17.
\nMesmo na versão 17, ainda será possível usá-los, mas eles terão um prefixo “UNSAFE_” para indicar que podem causar problemas. Nós também preparamos um script automatizado para renomeá-los no código existente.
\n
Além de depreciar ciclos de vida inseguros, também estamos adicionando alguns novos ciclos de vida:
\ngetDerivedStateFromProps está sendo adicionado como uma alternativa mais segura ao legado componentWillReceiveProps. (Note que na maioria dos casos você não precisa de nenhum deles.)getSnapshotBeforeUpdate está sendo adicionado para oferecer suporte para leitura segura das propriedades, por exemplo, do DOM, antes que as atualizações sejam feitas.Saiba mais sobre essas mudanças no ciclo de vida aqui.
\nStrictMode StrictMode é uma ferramenta para destacar possíveis problemas em um aplicativo. Como o Fragment, oStrictMode não renderiza nenhuma UI visível. Ele ativa verificações e avisos adicionais para seus descendentes.
\n\nNota:
\n\n
StrictModeas verificações são executadas apenas no modo de desenvolvimento; eles não afetam a estrutura de produção.
Embora não seja possível para o “strict mode” detectar todos os problemas (por exemplo, certos tipos de mutação), ele pode ajudar em muitos. Se você ver avisos no “strict mode”, essas coisas provavelmente causarão bugs para renderização assíncrona.
\nNa versão 16.3, o StrictMode ajuda:
Funcionalidades adicionais serão adicionadas com versões futuras do React.
\n","excerpt":"Há alguns dias, escrevemos uma postagem sobre as próximas mudanças em nossos métodos de ciclo de vida legados, incluindo estratégias de migração gradual. No React 16.3.0, estamos adicionando alguns novos métodos de ciclo de vida para ajudar nessa migração. Também estamos introduzindo novas APIs para funcionalidades há tempo solicitadas: uma API de contexto oficial, uma API de referência de encaminhamento e uma API de referência de ergonomia. Leia para saber mais sobre o lançamento. API Oficial…","frontmatter":{"title":"React v16.3.0: Novos ciclos de vida e API de contexto","next":null,"prev":null,"author":[{"frontmatter":{"name":"Brian Vaughn","url":"https://github.com/bvaughn"}}]},"fields":{"date":"29 de março de 2018","path":"content/blog/2018-03-29-react-v-16-3.md","slug":"/blog/2018/03/29/react-v-16-3.html"}},"allMarkdownRemark":{"edges":[{"node":{"frontmatter":{"title":"React v17.0"},"fields":{"slug":"/blog/2020/10/20/react-v17.html"}}},{"node":{"frontmatter":{"title":"Apresentando o novo JSX Transform"},"fields":{"slug":"/blog/2020/09/22/introducing-the-new-jsx-transform.html"}}},{"node":{"frontmatter":{"title":"React v17.0 Candidato à lançamento: Sem novas funcionalidades"},"fields":{"slug":"/blog/2020/08/10/react-v17-rc.html"}}},{"node":{"frontmatter":{"title":"React v16.13.0"},"fields":{"slug":"/blog/2020/02/26/react-v16.13.0.html"}}},{"node":{"frontmatter":{"title":"Construindo Ótimas Experiências de Usuário com Modo Concorrente e Suspense"},"fields":{"slug":"/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html"}}},{"node":{"frontmatter":{"title":"Preparando para o Futuro com as Prereleases React"},"fields":{"slug":"/blog/2019/10/22/react-release-channels.html"}}},{"node":{"frontmatter":{"title":"Apresentando o novo React DevTools"},"fields":{"slug":"/blog/2019/08/15/new-react-devtools.html"}}},{"node":{"frontmatter":{"title":"React v16.9.0 e a atualização do Roadmap"},"fields":{"slug":"/blog/2019/08/08/react-v16.9.0.html"}}},{"node":{"frontmatter":{"title":"O React já esta traduzido? ¡Sí! Sim! はい！"},"fields":{"slug":"/blog/2019/02/23/is-react-translated-yet.html"}}},{"node":{"frontmatter":{"title":"React v16.8: O React com Hooks"},"fields":{"slug":"/blog/2019/02/06/react-v16.8.0.html"}}}]}},"pageContext":{"slug":"/blog/2018/03/29/react-v-16-3.html"}},"staticQueryHashes":[]}