Memoização no React: ferramenta poderosa ou armadilha oculta?

Uma abordagem generalizada no desenvolvimento de aplicativos React é cobrir tudo com memoização. Muitos desenvolvedores aplicam essa técnica de otimização liberalmente, agrupando componentes em memoização para evitar novas renderizações desnecessárias. Superficialmente, parece uma estratégia infalível para melhorar o desempenho. No entanto, a equipe descobriu que, quando mal aplicada, a memoização pode falhar de maneiras inesperadas, levando a problemas de desempenho. Neste artigo, exploraremos os lugares surpreendentes onde a memorização pode falhar e como evitar essas armadilhas ocultas em seus aplicativos React. do Social Discovery Group O que é memorização? Memoização é uma técnica de otimização em programação que envolve salvar os resultados de operações caras e reutilizá-los quando as mesmas entradas forem encontradas novamente. A essência da memoização é evitar cálculos redundantes para os mesmos dados de entrada. Esta descrição é realmente verdadeira para a memoização tradicional. Você pode ver no exemplo de código que todos os cálculos são armazenados em cache. const cache = { } function calculate (a) { if (Object.hasOwn(cache, a)) { return cache[a] } cache[a] = a * a return cache[a] } A memorização oferece vários benefícios, incluindo melhoria de desempenho, economia de recursos e armazenamento em cache de resultados. No entanto, a memorização do React funciona até que novos adereços cheguem, o que significa que apenas o resultado da última chamada é salvo. const prev = { value: null, result: null } function calculate(a) { if (prev.value === a) { return prev.result } prev.value = a prev.result = a * a return prev.result } Ferramentas de memorização em React A biblioteca React nos fornece diversas ferramentas para memorização. Estes são o HOC React.memo, os ganchos useCallback, useMemo e useEvent, bem como React.PureComponent e o método de ciclo de vida dos componentes da classe, shouldComponentUpdate. Vamos examinar as três primeiras ferramentas de memorização e explorar seus propósitos e uso no React. React.memo Este componente de ordem superior (HOC) aceita um componente como seu primeiro argumento e uma função de comparação opcional como segundo. A função de comparação permite a comparação manual de adereços anteriores e atuais. Quando nenhuma função de comparação é fornecida, o React assume como padrão a igualdade superficial. É crucial compreender que a igualdade superficial apenas realiza uma comparação no nível superficial. Conseqüentemente, se os adereços contiverem tipos de referência com referências não constantes, o React irá acionar uma nova renderização do componente. const Button = memo((props) => { return ( {props.title} ) }, (prevProps, props) => { return props.title === prevProps.title }) React.useCallback O gancho useCallback nos permite preservar a referência a uma função passada durante a renderização inicial. Nas renderizações subsequentes, o React comparará os valores na matriz de dependência do gancho e, se nenhuma das dependências tiver sido alterada, retornará a mesma referência de função em cache da última vez. Em outras palavras, useCallback armazena em cache a referência à função entre renderizações até que suas dependências sejam alteradas. const callback = useCallback(() => { // do something }, [a, b, c]) React.useMemo O gancho useMemo permite armazenar em cache o resultado de um cálculo entre renderizações. Normalmente, useMemo é usado para armazenar em cache cálculos caros, bem como para armazenar uma referência a um objeto ao passá-lo para outros componentes agrupados no memo HOC ou como uma dependência em ganchos. const value = useMemo(() => { return [1, 2, 3, 4, 5].filter(it => it % 2 === 0) }, []) Memoização completa de um projeto Nas equipes de desenvolvimento do React, uma prática difundida é a memorização abrangente. Essa abordagem normalmente envolve: Envolvendo todos os componentes em React.memo Usando useCallback para todas as funções passadas para outros componentes Cache de cálculos e tipos de referência com useMemo No entanto, os desenvolvedores nem sempre compreendem as complexidades desta estratégia e como a memoização pode ser facilmente comprometida. Não é incomum que componentes incluídos no memorando HOC sejam renderizados novamente inesperadamente. No Social Discovery Group, ouvimos colegas afirmarem: “Memorizar tudo não é muito mais caro do que não memorizar nada”. Notamos que nem todos compreendem totalmente um aspecto crucial da memoização: ela funciona de maneira ideal, sem ajustes adicionais, apenas quando os primitivos são passados para o componente memoizado. Nesses casos, o componente será renderizado novamente somente se os valores prop tiverem realmente mudado. Primitivos em adereços são bons. O segundo ponto é quando passamos tipos de referência em adereços. É importante lembrar e compreender que não existe mágica no React – é uma biblioteca JavaScript que opera de acordo com as regras do JavaScript. Tipos de referência em adereços (funções, objetos, arrays) são perigosos. Por exemplo: const a = { c: 1 } const b = { c: 1 } a === b // false First call: MemoComponent(a) Second call: MemoComponent(b) const MemoComponent = memo(({object}) => { return }, (prevProps, props) => (prevProps.object === props.object)) // false Se você criar um objeto, outro objeto com as mesmas propriedades e valores não será igual ao primeiro porque possuem referências diferentes. Se passarmos o que parece ser o mesmo objeto em uma chamada subsequente do componente, mas na verdade é diferente (já que sua referência é diferente), a comparação superficial que o React usa reconhecerá esses objetos como diferentes. Isso irá acionar uma nova renderização do componente envolvido no memo, quebrando assim a memorização desse componente. Para garantir uma operação segura com componentes memorizados, é importante usar uma combinação de memo, useCallback e useMemo. Desta forma, todos os tipos de referência terão referências constantes. Trabalho em equipe: memo, useCallback, useMemo Vamos quebrar o memorando, certo? Tudo o que foi descrito acima parece lógico e simples, mas vamos dar uma olhada juntos nos erros mais comuns que podem ser cometidos ao trabalhar com essa abordagem. Alguns deles podem ser sutis e alguns podem ser um pouco exagerados, mas precisamos estar cientes deles e, o mais importante, entendê-los para garantir que a lógica que implementamos com memoização completa não seja quebrada. Inline para memoização Vamos começar com um erro clássico, onde em cada renderização subsequente do componente Parent, o componente memorizado MemoComponent será constantemente renderizado novamente porque a referência ao objeto passado nos parâmetros sempre será nova. const Parent = () => { return ( ) } Para resolver este problema, basta usar o gancho useMemo mencionado anteriormente. Agora, a referência ao nosso objeto será sempre constante. const Parent = () => { const params = useMemo(() => { return [1, 2 ,3] ), []) return ( ) } Alternativamente, você pode mover isso para uma constante fora do componente se a matriz sempre contiver dados estáticos. const params = [1, 2 ,3] const Parent = () => { return ( ) } Uma situação semelhante neste exemplo é passar uma função sem memorização. Neste caso, como no exemplo anterior, a memorização do MemoComponent será quebrada passando-se para ele uma função que terá uma nova referência a cada renderização do componente Parent. Conseqüentemente, MemoComponent será renderizado novamente como se não tivesse sido memorizado. const Parent = () => { return ( {}} /> ) } Aqui, podemos usar o gancho useCallback para preservar a referência à função passada entre renderizações do componente Parent. const Parent = () => { const handleClick = useCallback(() => console.log('click') }, []) return ( ) } Nota tomada. Além disso, em useCallback, não há nada que impeça você de passar uma função que retorne outra função. Porém, é importante lembrar que nesta abordagem, a função `someFunction` será chamada em cada renderização. É crucial evitar cálculos complexos dentro de `someFunction`. function someFunction() { // expensive calculations (?) ... return () => {} } .............................. const Parent = () => { const cachedFunction = useCallback(someFunction(), []) return ( ) } Adereços espalhando A próxima situação comum é a propagação de adereços. Imagine que você tem uma cadeia de componentes. Com que frequência você considera a distância que o suporte de dados passado do InitialComponent pode percorrer, sendo potencialmente desnecessário para alguns componentes desta cadeia? Neste exemplo, esta propriedade quebrará a memorização no componente ChildMemo porque, a cada renderização do InitialComponent, seu valor sempre mudará. Em um projeto real, onde a cadeia de componentes memoizados pode ser longa, toda memoização será quebrada porque adereços desnecessários com valores em constante mudança são passados para eles: const Child = () => {} const ChildMemo = React.memo(Child) const Component = (props) => { return } const InitialComponent = (props) => { // The only component that has state and can trigger a re-render return ( ) } Para se proteger, certifique-se de que apenas os valores necessários sejam passados para o componente memorizado. Ao invés disso: const Component = (props) => { return } Use (passe apenas os adereços necessários): const Component = (props) => { return ( ) ) Memorando e filhos Vamos considerar o seguinte exemplo. Uma situação familiar é quando escrevemos um componente que aceita JSX como filho. const ChildMemo = React.memo(Child) const Component = () => { return ( Text ) } À primeira vista parece inofensivo, mas na realidade não é. Vamos dar uma olhada mais de perto no código onde passamos JSX como filhos para um componente memoizado. Esta sintaxe nada mais é do que um açúcar sintático para passar este `div` como um suporte chamado `children`. Os filhos não são diferentes de qualquer outro adereço que passamos para um componente. No nosso caso, estamos passando JSX, e JSX, por sua vez, é um açúcar sintático para o método `createElement`, então essencialmente, estamos passando um objeto regular com o tipo `div`. E aqui, a regra usual para um componente memoizado se aplica: se um objeto não memoizado for passado nos adereços, o componente será renderizado novamente quando seu pai for renderizado, pois cada vez que a referência a este objeto será nova. A solução para tal problema foi discutida alguns resumos anteriormente, no bloco referente à passagem de um objeto não memorizado. Portanto, aqui, o conteúdo que está sendo passado pode ser memorizado usando useMemo, e passá-lo como filho para ChildMemo não interromperá a memorização deste componente. const Component = () => { const childrenContent = useMemo( () => Text , [], ) return ( {childrenContent} ) } ParentMemo e ChildMemo Vamos considerar um exemplo mais interessante. const ParentMemo = React.memo(Parent) const ChildMemo = React.memo(Child) const App = () => { return ( ) } À primeira vista parece inofensivo: temos dois componentes, ambos memorizados. Entretanto, neste exemplo, ParentMemo se comportará como se não estivesse agrupado em memo porque seus filhos, ChildMemo, não foram memorizados. O resultado do componente ChildMemo será JSX, e JSX é apenas um açúcar sintático para React.createElement, que retorna um objeto. Portanto, após a execução do método React.createElement, ParentMemo e ChildMemo se tornarão objetos JavaScript regulares e esses objetos não serão memorizados de forma alguma. ParentMemo CriançaMemorando {`` type: {`` ...`` $$typeof: Symbol(react.memo),`` type: {`` name: "Parent"`` }`` },`` ...``} {`` type: {`` ...`` $$typeof: Symbol(react.memo),`` type: {`` name: "Child"`` }`` },`` ...``} Como resultado, passamos um objeto não memorizado para os adereços, quebrando assim a memorização do componente Parent. const ParentMemo = React.memo(Parent) const ChildMemo = React.memo(Child) const App = () => { return ( } /> ) } Para resolver esse problema, é suficiente memorizar o filho passado, garantindo que sua referência permaneça constante durante a renderização do componente App pai. const App = () => { const child = useMemo(() => { return }, []); return ( {child} ) } Não primitivos de ganchos personalizados Outra área perigosa e implícita são os ganchos personalizados. Ganchos personalizados nos ajudam a extrair lógica de nossos componentes, tornando o código mais legível e ocultando lógica complexa. No entanto, eles também nos escondem se seus dados e funções têm referências constantes. No meu exemplo, a implementação da função submit está oculta no gancho personalizado useForm e, em cada renderização do componente Parent, os ganchos serão executados novamente. const Parent = () => { const { submit } = useForm() return }; Podemos entender pelo código se é seguro passar o método submit como um suporte para o componente memorizado ComponentMemo? Claro que não. E na pior das hipóteses, a implementação do gancho personalizado pode ser assim: const Parent = () => { const { submit } = useForm() return }; const useForm = () => { const submit = () => {} return { submit } } Ao passar o método submit para o componente memoized, quebraremos a memoização porque a referência ao método submit será nova a cada renderização do componente Parent. Para resolver esse problema, você pode usar o gancho useCallback. Mas o ponto principal que gostaria de enfatizar é que você não deve usar cegamente dados de ganchos personalizados para passá-los para componentes memorizados se não quiser quebrar a memorização que você implementou. const Parent = () => { const { submit } = useForm() return }; const useForm = () => { const submit = useCallback(() => {}, []) return { submit } } Quando a memoização é excessiva, mesmo que você cubra tudo com memoização? Como qualquer abordagem, a memorização completa deve ser usada com cuidado e deve-se esforçar-se para evitar a memorização flagrantemente excessiva. Vamos considerar o seguinte exemplo: export function App() { const [state, setState] = useState('') const handleChange = (e) => { setState(e.target.value) } return ( ) } export const Input = memo((props) => ( )) Neste exemplo, é tentador agrupar o método handleChange em useCallback porque passar handleChange em sua forma atual interromperá a memorização do componente Input, pois a referência a handleChange sempre será nova. No entanto, quando o estado muda, o componente Input será renderizado novamente de qualquer maneira porque um novo valor será passado para ele na proposta de valor. Portanto, o fato de não agruparmos handleChange em useCallback não impedirá que o componente Input seja renderizado constantemente. Neste caso, usar useCallback seria excessivo. A seguir, gostaria de fornecer alguns exemplos de código real visto durante revisões de código. const activeQuestionNumber = useMemo(() => { return activeQuestionIndex + 1 }, [activeQuestionIndex]) const userAnswerImage = useMemo(() => { return `/i/call/quiz/${quizQuestionAnswer.userAnswer}.png` }, [quizQuestionAnswer.userAnswer]) Considerando o quão simples é a operação de adicionar dois números ou concatenar strings, e que obtemos primitivos como saída nesses exemplos, é óbvio que usar useMemo aqui não faz sentido. Exemplos semelhantes aqui. const cta = useMemo(() => { return activeOverlayName === 'photos' ? 'gallery' : 'profile' }, [activeOverlayName]) const attendeeId = useMemo(() => { return userId === senderId ? recipientId : senderId }, [userId, recipientId, senderId]) Com base nas dependências em useMemo, resultados diferentes podem ser obtidos, mas, novamente, são primitivos e não há cálculos complexos dentro deles. Executar qualquer uma dessas condições em cada renderização do componente é mais barato do que usar useMemo. Conclusões Otimização - nem sempre benéfica. *As otimizações de desempenho não são gratuitas e o custo dessas otimizações pode nem sempre ser proporcional aos benefícios que você obterá com elas. * Meça os resultados das otimizações. *Se você não medir, não poderá saber se suas otimizações melhoraram alguma coisa ou não. E o mais importante: sem medições, você não saberá se elas pioraram as coisas. * Meça a eficácia da memorização. *O uso ou não da memoização completa só pode ser entendido medindo seu desempenho em seu caso específico. A memorização não é gratuita ao armazenar em cache ou memorizar cálculos, e isso pode afetar a rapidez com que seu aplicativo é inicializado pela primeira vez e a rapidez com que os usuários podem começar a usá-lo. Por exemplo, se você deseja memorizar algum cálculo complexo cujo resultado precisa ser enviado ao servidor quando um botão é pressionado, você deve memorizá-lo quando sua aplicação for inicializada? Talvez não, porque há uma chance de o usuário nunca pressionar esse botão e executar esse cálculo complexo pode ser totalmente desnecessário. * Pense primeiro e depois memorize. * Memoizar adereços passados para um componente só faz sentido se ele estiver empacotado em `memo`, ou se os adereços recebidos forem usados nas dependências dos ganchos, e também se esses adereços forem passados para outros componentes memoizados. * Lembre-se dos princípios básicos do JavaScript. Ao trabalhar com React ou qualquer outra biblioteca e framework, é importante não esquecer que tudo isso é implementado em JavaScript e opera de acordo com as regras desta linguagem. Quais ferramentas podem ser usadas para medição? Podemos recomendar pelo menos 4 dessas ferramentas para medir o desempenho do código do seu aplicativo. React.Profiler Com , você pode agrupar o componente específico necessário ou o aplicativo inteiro para obter informações sobre o horário das renderizações inicial e subsequente. Você também pode entender em qual fase exata a métrica foi obtida. React.Profiler Ferramentas de desenvolvedor React é uma extensão do navegador que permite inspecionar a hierarquia de componentes, rastrear alterações em estados e adereços e analisar o desempenho do aplicativo. Ferramentas de desenvolvedor React Rastreador de renderização React Outra ferramenta interessante é , o que ajuda a detectar re-renderizações potencialmente desnecessárias quando props em componentes não memorizados não mudam ou mudam para similares. Rastreador de renderização React Livro de histórias com o complemento storybook-addon-performance. Além disso, no Storybook, você pode instalar um plugin interessante chamado da Atlassian. Com este plugin, você pode executar testes para obter informações sobre a velocidade de renderização inicial, re-renderização e renderização do lado do servidor. Esses testes podem ser executados em múltiplas cópias, bem como em múltiplas execuções simultaneamente, minimizando imprecisões nos testes. desempenho de complemento de livro de histórias ** Escrito por Sergey Levkovich, engenheiro de software sênior do Social Discovery Group

Memoização no React: ferramenta poderosa ou armadilha oculta?

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps