Hooks são uma nova adição ao React 16.8. Eles permitem que você use o state e outros recursos do React sem escrever uma classe.
\nEsta página responde algumas das perguntas mais frequentes sobre Hooks.
\n\nComeçando com 16.8.0, React inclui uma implementação estável dos Hooks para:
\nNote que para habilitar Hooks, todos os pacotes precisam estar na versão 16.8.0 ou maior. Hooks não vão funcionar se você esquecer de atualizar, por exemplo, o React DOM.
\nReact Native 0.59 e superiores suportam Hooks.
\nNão. Não existe nenhum plano para remover classes do React — todos nós precisamos continuar entregando produtos e não podemos reescrever tudo. Recomendamos tentar usar Hooks em código novo.
\nHooks oferecem uma nova maneira, poderosa e expressiva, de reutilizar funcionalidade entre componentes. “Construindo Seu Próprio Hook” fornece um vislumbre do que é possível. Este artigo feito por um membro da equipe principal do React mergulha fundo nas novas possibilidades desbloqueadas por Hooks.
\nHooks são uma maneira mais direta de usar as funcionalidades do React que você já conhece — como estado, ciclo de vida, context e refs. Eles não mudam fundamentalmente como o React funciona e seu conhecimento de componentes, props e fluxo de dados de cima para baixo continua relevante.
\nHooks tem sua curva de aprendizado. Se tiver algo faltando nessa documentação, abra um issue e nós vamos tentar ajudar.
\nQuando você estiver pronto, encorajamos você a começar usando Hooks em novos componentes que você escrever. Tenha certeza que todos no seu time estão de acordo em usá-los e estão familiarizados com a documentação. Nós não recomendamos reescrever suas classes existentes para Hooks a menos que você tenha planejado reescrevê-las previamente (por exemplo, para arrumar bugs).
\nVocê não pode usar Hooks dentro de um componente classe, mas você definitivamente pode misturar classes e funções com Hooks em uma única árvore. Se um componente é uma classe ou uma função que usa Hooks é um detalhe de implementação daquele componente. A longo prazo, nós esperamos que Hooks sejam a principal maneira que as pessoas escrevam componentes React.
\nNosso objetivo é que Hooks cubra todos os casos de uso o mais rápido possível. Ainda não há Hook equivalente para os ciclos de vida getSnapshotBeforeUpdate, getDerivedStateFromError e componentDidCatch, que são mais incomuns, mas planejamos adiciona-los em breve.
É o início dos Hooks e algumas bibliotecas de terceiros podem não ser compatíveis com Hooks neste momento.
\nFrequentemente, render props e HOC renderizam somente um filho. Nós achamos que Hooks são uma maneira mais simples de atender esse caso de uso. Ainda existe lugar para ambos os padrões (por exemplo, um componente de scroll virtual talvez tenha uma prop renderItem, ou um container visual talvez tenha sua própria estrutura DOM). Mas na maioria dos casos, Hooks serão suficiente e podem ajudar a reduzir o aninhamento na sua árvore.
connect() do Redux e o React Router? Você pode continuar a usar exatamente as mesmas APIs que sempre usou; elas vão continuar funcionando.
\nReact Redux desde a v7.1.0 suporta Hooks API e expõe hooks como useDispatch ou useSelector.
React Router suporta hooks desde a v5.1.
\nOutras bibliotecas também podem suportar hooks no futuro.
\nHooks foram planejados com tipagem estática em mente. Como eles são funções, eles são mais fáceis de tipar corretamente do que padrões como high-order components. As últimas definições do React para Flow e Typescript incluem suporte para React Hooks.
\nImportante observar, que Hooks customizados te dão o poder de restringir a API do React se você quiser usa-la de alguma maneira mais rigorosa. React te dá as primitivas mas você pode combina-las de diferentes maneiras além das que fornecemos.
\nDo ponto de vista do React, um componente usando Hooks é somente um componente regular. Se sua solução para testes não depende do funcionamento interno do React, testar componentes com Hooks não deveria ser diferente de como você normalmente testa componentes.
\n\n\nNota
\nEm Testing Recipes tem muitos exemplos que você pode copiar e colar.
\n
Por exemplo, digamos que temos este componente contador:
\nfunction Example() {\n const [count, setCount] = useState(0);\n useEffect(() => {\n document.title = `You clicked ${count} times`;\n });\n return (\n <div>\n <p>You clicked {count} times</p>\n <button onClick={() => setCount(count + 1)}>\n Click me\n </button>\n </div>\n );\n}Nós vamos testa-lo usando React DOM. Para garantir que o comportamento corresponde ao que acontece no browser, nós vamos envolver o código que renderiza e atualiza com ReactTestUtils.act():
import React from 'react';\nimport ReactDOM from 'react-dom';\nimport { act } from 'react-dom/test-utils';import Counter from './Counter';\n\nlet container;\n\nbeforeEach(() => {\n container = document.createElement('div');\n document.body.appendChild(container);\n});\n\nafterEach(() => {\n document.body.removeChild(container);\n container = null;\n});\n\nit('can render and update a counter', () => {\n // Testa a primeira renderização e efeito\n act(() => { ReactDOM.render(<Counter />, container); }); const button = container.querySelector('button');\n const label = container.querySelector('p');\n expect(label.textContent).toBe('You clicked 0 times');\n expect(document.title).toBe('You clicked 0 times');\n\n // Testa segunda renderização e efeito\n act(() => { button.dispatchEvent(new MouseEvent('click', {bubbles: true})); }); expect(label.textContent).toBe('You clicked 1 times');\n expect(document.title).toBe('You clicked 1 times');\n});As chamadas para act() também vão descarregar os efeitos dentro dele.
Se você precisa testar um Hook customizado, você pode faze-lo criando um componente no seu teste e usando o seu Hook nele. Então você pode testar o componente que escreveu.
\nPara reduzir o boilerplate, nós recomendamos usar React Testing Library que é projetada para incentivar a escrever testes que usam seus componentes como usuários finais usam.
\nPara mais informações, confira Testing Recipes.
\nNós fornecems um plugin ESLint que impõem regras de Hooks para evitar bugs. Elas assumem que qualquer função começando com ”use” e uma letra maiúscula em segunda é um Hook. Nós reconhecemos que esta heurística não é perfeita e que talvez aconteçam alguns falso positivos mas sem uma convenção simplesmente não há como fazer Hooks funcionarem bem — e nomes mais longos iriam desencorajar pessoas tanto de adotar Hooks ou de seguir a convenção.
Em particular, a regra impõe que:
\nPascalCase (tratada como componente) ou dentro de outra função useSomething (tratada como um Hook customizado).Existem mais algumas heurísticas e talvez elas mudem ao longo do tempo conforme nós regulamos as regras para balancear entre encontrar bugs e evitar falsos positivos.
\nconstructor: Funções não precisam de um constructor. Você pode inicializar o estado com o useState. Se calcular o estado for custoso, você pode passar uma função para o useState.getDerivedStateFromProps: Não é necessário, agende um update enquanto estiver renderizando.shouldComponentUpdate: Veja React.memo abaixo.render: Este é o próprio corpo da função.componentDidMount, componentDidUpdate, componentWillUnmount: O Hook useEffect pode expressar todas as combinações desses, (incluindo casos menos comuns).getSnapshotBeforeUpdate, componentDidCatch e getDerivedStateFromError: Não há Hooks equivalentes para esses métodos ainda, mas eles serão adicionados em breve.Aqui está uma pequena demonstração para você começar. Para saber mais, confira o artigo sobre a obtenção de dados com Hooks.
\nSim! O Hook useRef() não é somente para DOM. O objeto “ref” é um container genérico no qual a propriedade current é mutável e pode conter qualquer valor, similar a uma propriedade de instância de uma classe.
Você pode escrever nele de dentro do useEffect:
function Timer() {\n const intervalRef = useRef();\n useEffect(() => {\n const id = setInterval(() => {\n // ...\n });\n intervalRef.current = id; return () => {\n clearInterval(intervalRef.current);\n };\n });\n\n // ...\n}Se nós só quiséssemos criar um intervalo, não precisaríamos de ref (id poderia ser local do efeito), mas é útil se quisermos limpar o intervalo usando um manipulador de eventos:
// ...\n function handleCancelClick() {\n clearInterval(intervalRef.current); }\n // ...Conceitualmente, você pode pensar em refs como similares a variávels de instância em uma classe. A menos que você esteja fazendo inicialização lazy, evite definir refs durante a renderização — isso pode levar a comportamentos inesperados. Ao invés disso, normalmente você deseja modificar as refs nos manipuladores de eventos e efeitos.
\nSe você está vindo de classes, você pode ser tentado a sempre chamar useState() uma vez e por todo o estado em um único objeto. Você pode fazer isso se quiser. Aqui segue um exemplo de um componente que segue o movimento do mouse. Nós guardamos sua posição e tamanho no estado local:
function Box() {\n const [state, setState] = useState({ left: 0, top: 0, width: 100, height: 100 });\n // ...\n}Agora vamos dizer que queremos escrever uma lógica que muda left e top quando o usuário move o seu mouse. Note que nós temos que mesclar esses campos no estado anterior manualmente:
// ...\n useEffect(() => {\n function handleWindowMouseMove(e) {\n // Espalhando \"...state\" garante que width e height não se \"percam\" setState(state => ({ ...state, left: e.pageX, top: e.pageY })); }\n // Nota: essa implementação é um pouco simplificada\n window.addEventListener('mousemove', handleWindowMouseMove);\n return () => window.removeEventListener('mousemove', handleWindowMouseMove);\n }, []);\n // ...Isto é porque quando atualizamos uma variável de estado, nós substituimos seu valor. É diferente de this.setState em uma classe, que mescla os campos atualizados no objeto.
Se você sente falta da mesclagem automática, você poderia escrever um Hook customizado, useLegacyState, que mescla o update no objeto. No entanto, nós recomendamos dividir o estado em múltiplas variáveis de estado baseado nos valores que tendem a mudar juntos.
Por exemplo, poderíamos dividir nosso componente em position e size e sempre substituir position sem a necessidade de mesclar:
function Box() {\n const [position, setPosition] = useState({ left: 0, top: 0 }); const [size, setSize] = useState({ width: 100, height: 100 });\n\n useEffect(() => {\n function handleWindowMouseMove(e) {\n setPosition({ left: e.pageX, top: e.pageY }); }\n // ...Separar o estado em variáveis independentes também tem outro benefício. Torna mais fácil para extrair uma lógica relacionada para um Hook customizado posteriormente, como por exemplo:
\nfunction Box() {\n const position = useWindowPosition(); const [size, setSize] = useState({ width: 100, height: 100 });\n // ...\n}\n\nfunction useWindowPosition() { const [position, setPosition] = useState({ left: 0, top: 0 });\n useEffect(() => {\n // ...\n }, []);\n return position;\n}Note como nós conseguimos mover a chamada useState da variável de estado position e o efeito relacionado para um Hook customizado sem alterar o seu código. Se todo o estado estivesse em um único objeto, extrair seria mais difícil.
Tanto colocar todo estado em um único useState e usar múltiplos useState para cada campo pode funcionar. Componentes tendem a ser mais legíveis quando você encontra um balanço entre esses dois extremos e agrupa estados relacionados em algunas variáveis de estado independentes. Se a lógica do estado se torna muito complexa, nós recomendamos gerenciá-la com um reducer ou com um Hook customizado.
Esse é um caso de uso raro. Se você precisar, você pode usar uma ref mutável para manualmente armazenar um valor boleano correspondente a se você está no primeiro render ou num subsequente, usando então essa flag no seu efeito. (Se você se encontrar fazendo isso regularmente, pode criar um Hook customizado pra isso.)
\nAtualmente, você pode fazer isso manualmente com uma ref:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n const prevCountRef = useRef();\n useEffect(() => {\n prevCountRef.current = count; });\n const prevCount = prevCountRef.current;\n return <h1>Now: {count}, before: {prevCount}</h1>;\n}Isso pode ser um pouco confuso mas você pode extrair para um Hook customizado:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n const prevCount = usePrevious(count); return <h1>Now: {count}, before: {prevCount}</h1>;\n}\n\nfunction usePrevious(value) { const ref = useRef();\n useEffect(() => {\n ref.current = value;\n });\n return ref.current;\n}Note como isso funcionaria para props, state ou qualquer outro valor calculado.
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n const calculation = count + 100;\n const prevCalculation = usePrevious(calculation); // ...É possível que no futuro o React forneça um Hook usePrevious pois esse é um caso de uso relativamente comum.
Veja também o padrão recomendado para estado derivado.
\nQualquer função dentro de um componente, incluindo manipuladores de eventos e efeitos, “vê” as props e o state da renderização em que foi criado. Por exemplo, considere este código:
\nfunction Example() {\n const [count, setCount] = useState(0);\n\n function handleAlertClick() {\n setTimeout(() => {\n alert('Você clicou: ' + count);\n }, 3000);\n }\n\n return (\n <div>\n <p>You clicked {count} times</p>\n <button onClick={() => setCount(count + 1)}>\n Mostrar\n </button>\n <button onClick={handleAlertClick}>\n Mostrar aviso\n </button>\n </div>\n );\n}Se você clicar primeiro em “Mostrar aviso” e incrementar o contador, o alerta mostrará a variável count no momento em que clicou no botão “Mostrar alerta”. Isso evita erros causados pelo código assumindo props e state não muda.
Se você intencionalmente queser ler o state lastest de algum retorno de chamada assincrono, você poderia mantê-lo em uma ref, mude-o e leia a partir dele.
\nFinalmente, outro possível motivo que você está vendo props obsoletos ou state é se você usa a otimização do “array de dependência”, mas não especificou corretamente todas as dependências. Por exemplo, se um efeito especifica [] como o segundo argumento mas lê someProp dentro, ele continuará “vendo” o valor inicial de someProps. A solução é remover o array de dependências ou corrigi-lo. Aqui está como você pode lidar com funções, e aqui está outras estratégias comuns para executar efeitos com menos frequência sem ignorar incorretamente as dependências.
\n\nNota
\nRecomendamos usar as regras do
\nexhaustive-depscomo parte do nosso pacoteeslint-plugin-react-hooks. Ele avisa quando as dependências são especificadas incorretamente e sugere uma correção.
getDerivedStateFromProps? Enquanto você provavelmente não precisa dele, nos raros casos que você precisar (como ao implementar um componente de <Transition>), você pode atualizar o estado enquanto estiver renderizando. React vai re-renderizar o componente com o estado atualizado imediatamente após sair do primeiro render, então não seria custoso.
Aqui, nós guardamos o valor anterior da prop row em uma variável de estado para que possamos comparar:
function ScrollView({row}) {\n const [isScrollingDown, setIsScrollingDown] = useState(false);\n const [prevRow, setPrevRow] = useState(null);\n\n if (row !== prevRow) {\n // Row mudou desde a ultima renderização. Atualize isScrollingDown.\n setIsScrollingDown(prevRow !== null && row > prevRow);\n setPrevRow(row);\n }\n\n return `Scrolling down: ${isScrollingDown}`;\n}Isto pode parecer estranho a princípio, mas um update durante o render é exatamente o que getDerivedStateFromProps sempre foi conceitualmente.
Ambos os Hooks useState e useReducer evitam atualizações se o próximo valor é igual ao anterior. Alterar o estado diretamente e chamar setState não vai causar uma re-renderização.
Normalmente, você não deve alterar o estado local no React. No entanto, como uma alternativa, você pode usar um contador incremental para forçar um re-render mesmo se o estado não mudou:
\n const [ignored, forceUpdate] = useReducer(x => x + 1, 0);\n\n function handleClick() {\n forceUpdate();\n }Tente evitar esse padrão se possível.
\nEnquanto você não deve precisar muito disso, você pode expor alguns métodos imperativos para um parente com o Hook useImperativeHandle.
Uma maneira rudimentar de medir a posição ou o tamanho de um nó DOM é usar um callback ref. React chamará esse callback sempre que a ref for anexado a um nó diferente. Aqui está uma pequena demonstração:
\nfunction MeasureExample() {\n const [height, setHeight] = useState(0);\n\n const measuredRef = useCallback(node => { if (node !== null) { setHeight(node.getBoundingClientRect().height); } }, []);\n return (\n <>\n <h1 ref={measuredRef}>Hello, world</h1> <h2>O header acima tem {Math.round(height)}px de altura</h2>\n </>\n );\n}Nós não escolhemos useRef neste exemplo porque um objeto ref não nos avisa sobre alterações para o valor atual da ref. A utilização de um callback ref garante que mesmo que um componente filho exiba o nó medido posteriormente (e.g. em resposta a um clique), ainda somos notificados sobre isso no componente pai e podemos atualizar as medições.
Note que nós passamos [] como um array de dependências para useCallback. Isso garante que nosso ref callback não seja alterado entre as novas renderizações e, portanto, o React não o chamará desnecessariamente.
Neste exemplo, a ref de callback será chamado somente quando o componente for montado e desmontado, pois o componente renderizado <h1> permance presente em todos os repetidores. Se você deseja ser notificado sempre que um componente é redimensionado, você pode usar ResizeObserver ou uma Hook de terceiros construído sobre ele.
Se você quiser, você pode extrair essa lógica em um Hook reutilizável:
\nfunction MeasureExample() {\n const [rect, ref] = useClientRect(); return (\n <>\n <h1 ref={ref}>Hello, world</h1>\n {rect !== null &&\n <h2>O header acima tem {Math.round(rect.height)}px de altura</h2>\n }\n </>\n );\n}\n\nfunction useClientRect() {\n const [rect, setRect] = useState(null);\n const ref = useCallback(node => {\n if (node !== null) {\n setRect(node.getBoundingClientRect());\n }\n }, []);\n return [rect, ref];\n}const [thing, setThing] = useState() significa? Se essa sintaxe não é familiar para você, confira a explicação na documentação do Hook State.
\nSim. Veja disparando um efeito condicionalmente. Note que esquecer de lidar com updates geralmente introduz bugs, por isso que este não é o comportamento padrão.
\nDe um modo geral, não.
\nfunction Example({ someProp }) {\n function doSomething() {\n console.log(someProp); }\n\n useEffect(() => {\n doSomething();\n }, []); // 🔴 Isto não é seguro (ele chama `doSomething` que usa` someProp`)}É difícil lembrar quais props ou state são usados por funções fora do efeito. É por isso que normalmente você vai querer declarar funções necessárias para um efeito dentro dele. Então é fácil ver em quais valores do escopo do componente esse efeito depende:
\nfunction Example({ someProp }) {\n useEffect(() => {\n function doSomething() {\n console.log(someProp); }\n\n doSomething();\n }, [someProp]); // ✅ OK (nosso efeito usa apenas `someProp`)}Se depois disso ainda não usarmos nenhum valor do escopo do componente, é seguro especificar []:
useEffect(() => {\n function doSomething() {\n console.log('hello');\n }\n\n doSomething();\n}, []); // ✅ OK neste exemplo porque não usamos *nenhum* dos valores do escopo do componenteDependendo do seu caso de uso, existem mais algumas opções descritas abaixo.
\n\n\nNota
\nNós fornecemos o
\nexhaustive-depsregras do ESLint como parte do pacoteeslint-plugin-react-hooks. Ele ajuda você a encontrar componentes que não lidam com atualizações de forma consistente.
Vamos ver porque isso é importante.
\nSe você especificar uma lista de dependências como o último argumento para useEffect, useLayoutEffect, useMemo, useCallback, ou useImperativeHandle, ele deve incluir todos os valores usados dentro do callback e participar do fluxo de dados React. Isso inclui props, state e qualquer coisa derivada deles.
É somente seguro omitir uma função da lista de dependências se nada nela (ou as funções chamadas por ela) referenciar props, state ou valores derivados deles. Este exemplo tem um erro:
\nfunction ProductPage({ productId }) {\n const [product, setProduct] = useState(null);\n\n async function fetchProduct() {\n const response = await fetch('http://myapi/product/' + productId); // // Usando productId prop const json = await response.json();\n setProduct(json);\n }\n\n useEffect(() => {\n fetchProduct();\n }, []); // 🔴 Inválido porque `fetchProduct` usa `productId` // ...\n}A correção recomendada é mover essa função inside do seu efeito. Isso torna mais fácil ver quais props ou state seu efeito usa e garantir que todos sejam declarados:
\nfunction ProductPage({ productId }) {\n const [product, setProduct] = useState(null);\n\n useEffect(() => {\n // Ao mover essa função dentro do efeito, podemos ver claramente os valores que ela usa. async function fetchProduct() { const response = await fetch('http://myapi/product/' + productId); const json = await response.json(); setProduct(json); }\n fetchProduct();\n }, [productId]); // ✅ Válido porque nosso efeito usa somente productId // ...\n}Isso também permite que você gerencie respostas fora de ordem com uma variável local dentro do efeito:
\n useEffect(() => {\n let ignore = false; async function fetchProduct() {\n const response = await fetch('http://myapi/product/' + productId);\n const json = await response.json();\n if (!ignore) setProduct(json); }\n\n fetchProduct();\n return () => { ignore = true }; }, [productId]);Nós movemos a função dentro do efeito para que não precise estar em sua lista de dependências.
\n\n\nDica
\nConfira esta pequena demostração e este artigo para saber mais sobre a obtenção de dados com Hooks.
\n
Se por alguma razão você não pode mover uma função dentro de um efeito, existem mais algumas opções:
\nuseCallback Hook. Isso garante que ele não seja alterado em todas as renderizações, a menos que suas próprias dependências também sejam alteradas:function ProductPage({ productId }) {\n // ✅ Envolva com useCallback para evitar alterações em todos os renderizadores const fetchProduct = useCallback(() => { // ... Faz algo com productId ... }, [productId]); // ✅ Todas as dependências useCallback são especificadas\n return <ProductDetails fetchProduct={fetchProduct} />;\n}\n\nfunction ProductDetails({ fetchProduct }) {\n useEffect(() => {\n fetchProduct();\n }, [fetchProduct]); // ✅ Todas as dependências do useEffect são especificadas\n // ...\n}Note que no exemplo acima nós precisamos para manter a função na lista de dependências. Isso garante que uma mudança na productId prop do ProductPage aciona automaticamente uma busca no componente ProductDetails.
Às vezes, seu efeito pode estar usando o state que muda com muita freqüência. Você pode ser tentado a omitir esse state de uma lista de dependências, mas isso geralmente leva a erros:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n useEffect(() => {\n const id = setInterval(() => {\n setCount(count + 1); // Este efeito depende do estado `count` }, 1000);\n return () => clearInterval(id);\n }, []); // 🔴 Bug: `count` não é especificado como uma dependência\n return <h1>{count}</h1>;\n}O conjunto vazio de dependências, [], significa que o efeito só será executado uma vez quando o componente for montado, e não em todas as re-renderizações. O problema é que dentro do callback setInterval, o valor de count não muda, porque nós criamos um fechamento com o valor de count configurando para 0 como era quando o retorno de chamada do efeito era executado. A cada segundo, este callback então chama setCount(0 + 1), então a contagem nunca vai acima de 1.
Especificando [count] como uma lista de dependências iria corrigir o bug, mas faria com que o intervalo fosse redefinido em cada alteração. Efetivamente, cada setInterval teria uma chance de executar antes de ser limpo (semelhante a um setTimeout). Isso pode não ser desejável. Para corrigir isso, podemos usar o form de atualização funcional do setState. Ele nos permite especificar como o state precisa mudar sem referenciar o state atual:
function Counter() {\n const [count, setCount] = useState(0);\n\n useEffect(() => {\n const id = setInterval(() => {\n setCount(c => c + 1); // ✅ Isso não depende da variável `count` fora }, 1000);\n return () => clearInterval(id);\n }, []); // ✅ Nosso efeito não usa nenhuma variável no escopo do componente\n return <h1>{count}</h1>;\n}(A identidade da função setCount é garantida como estável, então é seguro omitir.)
Agora, o retorno de chamada setInterval é executado uma vez por segundo, mas sempre que a chamada interna para setCount pode usar um valor atualizado para count (chamado c no retorno do callback aqui.)
Em casos mais complexos (como se um state dependesse de outro state), tente mover a lógica de atualização de state para fora do efeito com o useReducer Hook. O artigo oferece um exemplo de como você pode fazer isso. A identidade da função dispatch do useReducer é sempre estável — mesmo se a função reducer for declarada dentro do componente e ler seus props.
Como último recurso, se você quer algo como this em uma classe, você precisa usar uma ref para manter uma variável mutável. Então você pode escrever e ler para ele. Por exemplo:
function Example(props) {\n // Mantenha as últimas props em um ref. const latestProps = useRef(props); useEffect(() => { latestProps.current = props; });\n useEffect(() => {\n function tick() {\n // Leia as últimas props a qualquer momento console.log(latestProps.current); }\n\n const id = setInterval(tick, 1000);\n return () => clearInterval(id);\n }, []); // Esse efeito nunca é executado novamente}Só faça isso se você não conseguir encontrar uma alternativa melhor, confiar em mutação torna os componentes menos previsíveis. Se houver um padrão específico que não seja bem traduzido, abra uma issue com um código de exemplo executável e podemos tentar ajudar.
\nshouldComponentUpdate? Você pode envolver o componente de função com React.memo para comparar superficialmente suas props:
const Button = React.memo((props) => {\n // seu componente\n});Este não é um Hook porque não compõe como um Hook normalmente faz. React.memo é o equivalente de PureComponent, mas compara somente props. (Você pode também adicionar um segundo argumento para especificar uma função de comparação que recebe as props velhas e novas. Se esta retorna true, o update é evitado.)
React.memo não compara estado porque não há nenhum único objeto de estado para comparar. Mas você pode tornar filhos puros também, ou até otimizar filhos específicos com useMemo.
O Hook useMemo permite que você evite cáculos entre múltiplas renderizações se “lembrando” dos cálculos feitos anteriormente:
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);Esse código chama computeExpensiveValue(a, b). Mas se as dependências [a, b] não mudaram desde o último valor, useMemo não chama a função novamente e simplesmente retorna o valor retornado anteriormente.
Lembre-se que a função passada para useMemo é executada durante a renderização. Não faça nada que você normalmente não faria durante a renderização. Por exemplo, efeitos colaterais devem ser feitos usando useEffect, não useMemo.
Você pode confiar em useMemo como uma otimização de performace, não como uma garantia semântica. No futuro, React pode optar por “esquecer” alguns valores previamente memorizados e recalcular eles na próxima renderização, por exemplo para liberar memória para componentes fora da tela. Escreva seu código de maneira que ele funcione sem useMemo — e então adicione-o para otimizar o desempenho. (Para raros casos aonde um valor nunca deve ser recomputado, você pode inicializar posteriomente uma ref.)
Convenientemente, useMemo também deixa você pular uma re-renderização custosa de um filho:
function Parent({ a, b }) {\n // Somente re-renderizado se `a` muda:\n const child1 = useMemo(() => <Child1 a={a} />, [a]);\n // Somente re-renderizado se `b` muda:\n const child2 = useMemo(() => <Child2 b={b} />, [b]);\n return (\n <>\n {child1}\n {child2}\n </>\n )\n}Note que essa abordagem não vai funcionar em um loop porque Hooks não podem ser postos dentro de loops. Mas você pode extrair um componente separado para os items da lista e chamar useMemo nele.
useMemo permite memorizar um cálculo custoso se as dependências são as mesmas. No entanto, ele não garante que a computação não será re-executada. Algumas vezes você precisa ter certeza que um objeto só é criado uma vez.
O primeiro caso de uso comum é quando criar o estado inicial é custoso:
\nfunction Table(props) {\n // ⚠️ createRows() é executada em todo render\n const [rows, setRows] = useState(createRows(props.count));\n // ...\n}Para evitar re-criar o estado inicial, podemos passar uma função para useState:
function Table(props) {\n // ✅ createRows() só é executada uma vez\n const [rows, setRows] = useState(() => createRows(props.count));\n // ...\n}React só vai executar essa função durante a primeira renderização. Veja a API do useState.
Você também pode ocasionalmente querer evitar recriar o valor inicial de useRef(). Por exemplo, talvez você quer garantir que algumas instâncias de classe imperativa só seja criada uma vez:
function Image(props) {\n // ⚠️ IntersectionObserver é criado em todo render\n const ref = useRef(new IntersectionObserver(onIntersect));\n // ...\n}useRef não aceita uma função como useState. Ao invés disso, você pode criar sua própria função que cria e define-o posteriormente:
function Image(props) {\n const ref = useRef(null);\n\n // ✅ IntersectionObserver é criado somente uma vez\n function getObserver() {\n if (ref.current === null) {\n ref.current = new IntersectionObserver(onIntersect);\n }\n return ref.current;\n }\n\n // Quando você precisar, execute getObserver()\n // ...\n}Isto evita criar um objeto custoso até que ele seja realmente necessário pela primeira vez. Se você usa Flow ou TypeScript, você pode também dar getObserver() um tipo não nulo por conveniência.
Não. Nos browsers modernos, o desempenho bruto de closures comparados à classes não difere significantemente exceto em casos extremos.
\nEm adição, considere que o design de Hooks é mais eficiente por alguns motivos:
\nTradicionalmente, preocupações de desempenho sobre funções inline no React tem sido relacionadas a como passar novas callbacks em cada renderização quebra as otimizações de shouldComponentUpdate nos componentes filho. Hooks abordam esse problema de três maneiras.
O Hook useCallback permite que você mantenha a mesma callback entre re-renderizações para que shouldComponentUpdate continue a funcionar:
// Não vai mudar a menos que `a` ou `b` mude\nconst memoizedCallback = useCallback(() => { doSomething(a, b);\n}, [a, b]);useMemo torna mais fácil controlar quando filhos específicos atualizam, reduzindo a necessidade de pure components.useReducer reduz a necessidade de passar callbacks profundamente, como explicado abaixo.Nós descobrimos que a maioria das pessoas não gostam de passar callbacks manualmente através de cada nível de uma árvore de componente. Mesmo sendo mais explícito, pode parecer como um monte de “encanamento”.
\nEm árvores grandes de componentes, uma alternativa que recomendamos é passar para baixo a função dispatch do useReducer via context:
const TodosDispatch = React.createContext(null);\n\nfunction TodosApp() {\n // Nota: `dispatch` não vai mudar entre re-renderizações const [todos, dispatch] = useReducer(todosReducer);\n return (\n <TodosDispatch.Provider value={dispatch}>\n <DeepTree todos={todos} />\n </TodosDispatch.Provider>\n );\n}Qualquer filho na árvore dentro de TodosApp pode usar a função dispatch para disparar ações para o TodosApp:
function DeepChild(props) {\n // Se queremos executar uma ação, podemos pegar dispatch do context. const dispatch = useContext(TodosDispatch);\n function handleClick() {\n dispatch({ type: 'add', text: 'hello' });\n }\n\n return (\n <button onClick={handleClick}>Add todo</button>\n );\n}Isso é mais mais conveniente do ponto de vista de manutenção (não há a necessidade de passar callbacks) e evita o problema de passar callbacks como um todo. Passando dispatch desta maneira é o padrão recomendado para atualizações profundas.
Note que você ainda pode escolher entre passar o estado da aplicação para baixo como props (mais explícito) ou como context (mais conveniente para atualizações bem profundas). Se você também usar context para o estado, use dois tipos de context diferentes — o dispatch nunca muda, então componentes que leem ele não precisam re-renderizar a menos que precisem também do estado da aplicação.
\n\nNota
\nRecomendamos passar
\ndispatchpara baixo com context ao invés de callbacks individuais em props. A abordagem abaixo só é mencionada aqui para a integralidade e como válvula de escape.Note também que esse padrão pode causar problemas no modo concorrente. Planejamos prover mais alternativas ergonomicas no futuro, mas a solução mais segura no momento é sempre invalidar a callback se algum dos valores dos quais ela depende mudar.
\n
useCallback? Em alguns casos raros você pode precirar memorizar uma callback com useCallback mas a memorização não funciona muito bem porque a função interna tem que ser recriada muitas vezes. Se a função que você está memorizando é um manipulador de eventos e não é usado durante a renderização, você pode usar ref como uma variável de instância e salvar o último valor nela manualmente:
function Form() {\n const [text, updateText] = useState('');\n const textRef = useRef();\n\n useEffect(() => {\n textRef.current = text; // Guarda o valor na ref });\n\n const handleSubmit = useCallback(() => {\n const currentText = textRef.current; // Le o valor da ref alert(currentText);\n }, [textRef]); // Não recria handleSubmit como [text] faria\n\n return (\n <>\n <input value={text} onChange={e => updateText(e.target.value)} />\n <ExpensiveTree onSubmit={handleSubmit} />\n </>\n );\n}Este é um padrão um tanto confuso mas mostra que você pode usar essa válvula de escape se precisar. É mais suportável se você extrair para um Hook customizado:
\nfunction Form() {\n const [text, updateText] = useState('');\n // Será memorizado mesmo se `text` mudar:\n const handleSubmit = useEventCallback(() => { alert(text);\n }, [text]);\n\n return (\n <>\n <input value={text} onChange={e => updateText(e.target.value)} />\n <ExpensiveTree onSubmit={handleSubmit} />\n </>\n );\n}\n\nfunction useEventCallback(fn, dependencies) { const ref = useRef(() => {\n throw new Error('Cannot call an event handler while rendering.');\n });\n\n useEffect(() => {\n ref.current = fn;\n }, [fn, ...dependencies]);\n\n return useCallback(() => {\n const fn = ref.current;\n return fn();\n }, [ref]);\n}Em ambos os casos, não recomendamos esse padrão e só estamos mostrando aqui para integralidade. É melhor evitar passar callbacks para baixo.
\nReact acompanha o componente que está renderizando. Graças as Regras dos Hooks, sabemos que Hooks são chamados somente dentro de componentes React (ou Hooks customizados — que também só são chamados dentro de componentes React).
\nExiste uma lista interna de “células de memória” associadas a cada componente. Elas são somente objetos JavaScript aonde podemos colocar alguns dados. Quando você chama um Hook como useState(), é lido a célula atual (ou inicializada durante a primeira renderização), e então move o ponteiro para a próxima.é assim que múltiplas chamadas de useState() recebem seu estado local independente.
Hooks sintetizam ideias de diferentes fontes:
\nadopt como um auxiliar para render props, feito por Dominic Gannaway.Sebastian Markbåge criou o design original de Hooks, refinado posteriormente por Andrew Clark, Sophie Alpert, Dominic Gannaway, e outros membros do time principal do React.
","frontmatter":{"title":"Hooks FAQ","next":null,"prev":"hooks-reference.html"},"fields":{"path":"content/docs/hooks-faq.md","slug":"docs/hooks-faq.html"}}},"pageContext":{"slug":"docs/hooks-faq.html"}},"staticQueryHashes":[]}