Por que debounce e throttle são importantes nas interfaces

Determinados eventos do DOM são disparados em taxas extremamente altas. O evento de pressionamento de tecla é disparado a cada tecla pressionada. O evento de rolagem é disparado dezenas de vezes por segundo durante a rolagem. O evento de redimensionamento é disparado continuamente enquanto o usuário arrasta a borda da janela. Processar cada evento individualmente pode sobrecarregar tanto o navegador quanto o servidor.

Se o manipulador de pressionamento de tecla fizer uma chamada à API a cada tecla pressionada, um usuário que digite "React hooks" (11 caracteres) acionará 11 solicitações de rede, a maioria referente a consultas incompletas. Da mesma forma, atualizar uma animação de paralaxe a cada pixel de rolagem dispara centenas de novas renderizações do React por segundo. Isso desperdiça CPU, rede e bateria.

O atraso após a pausa adia a execução até que o evento pare de ser disparado durante um período especificado. Se o usuário ainda estiver digitando, o temporizador será reiniciado a cada tecla pressionada. Somente depois de N milissegundos de silêncio o manipulador finalmente será executado uma vez. O atraso após a pausa responde à pergunta: "execute isto depois que o usuário terminar de fazer algo".

A limitação de frequência restringe a execução a no máximo uma vez por intervalo de tempo, independentemente da quantidade de eventos disparados. Se o usuário rolar rapidamente, uma limitação de 100 ms garante que o manipulador seja executado no máximo 10 vezes por segundo. A limitação de frequência responde à pergunta: "execute isto regularmente, mas não com mais frequência do que a cada N ms".

O atraso após a pausa é a escolha certa quando você só se importa com o valor final depois que o usuário parar. Casos clássicos: campo de pesquisa (enviar a solicitação à API depois que a digitação pausar), manipulador de redimensionamento da janela (recalcular o layout depois que o redimensionamento terminar) e validação de campo de formulário que consulta um servidor (aguardar a entrada completa antes de validar).

A limitação de frequência é a escolha certa quando você quer atualizações regulares durante uma atividade contínua. Casos clássicos: manipulador da posição de rolagem (atualizar uma barra de progresso de leitura ou um cabeçalho fixo a no máximo 30 quadros por segundo), acompanhamento do movimento do mouse (registrar a posição do cursor para análise) e manipuladores de eventos de arraste (atualizar suavemente a posição de um elemento arrastável sem inundar o sistema).

Escrever um atraso após a pausa ou uma limitação de frequência do zero sem compreender completamente o funcionamento pode causar erros, como perder o evento final (borda final), disparar na borda errada ou não limpar os temporizadores quando o componente for desmontado. Em geral, é melhor usar implementações testadas em situações reais de bibliotecas como lodash, que lidam corretamente com todos os casos extremos.

O Lodash fornece _.debounce(fn, wait) e _.throttle(fn, wait), com opções para o comportamento nas bordas inicial e final. A função retornada tem um método .cancel() para cancelar uma invocação pendente e um método .flush() para executá-la imediatamente. No React, essas funções devem ser encapsuladas em useRef para evitar sua recriação durante uma nova renderização.

Até mesmo 50 novas renderizações extras do React por segundo causadas por um manipulador de rolagem sem limitação de frequência podem consumir uma quantidade significativa de CPU, especialmente em dispositivos móveis de baixo desempenho. Um orçamento de 16 ms por quadro (60 quadros por segundo) significa que cada nova renderização deve ser concluída em menos de 16 milissegundos para evitar a perda de quadros. O atraso após a pausa e a limitação de frequência são sua primeira linha de defesa contra problemas na taxa de quadros.

Nem todo manipulador de alta frequência precisa de um atraso após a pausa. Se o manipulador de eventos apenas ler um valor sem atualizar o estado nem chamar APIs — por exemplo, registrar a última posição do mouse em uma referência —, nenhum atraso será necessário. Aplique atraso após a pausa ou limitação de frequência somente aos manipuladores que acionam operações dispendiosas: atualizações de estado, chamadas à API ou medições do DOM.

Quando um componente é desmontado, qualquer chamada pendente com atraso após a pausa deve ser cancelada para evitar uma atualização de estado depois da desmontagem. Se você usar um useRef para armazenar a função com atraso, chame debouncedFn.cancel() na limpeza de useEffect. As funções com atraso do Lodash disponibilizam esse método exatamente para essa finalidade.

Qual técnica você deve usar para disparar uma chamada à API quando o usuário parar de digitar em um campo de pesquisa?

Eventos de alta frequência, como pressionamento de tecla, rolagem e redimensionamento, podem causar problemas de desempenho se os manipuladores forem executados a cada evento. O atraso após a pausa aguarda o silêncio e é melhor para campos de pesquisa e manipuladores de redimensionamento. A limitação de frequência restringe a frequência e é melhor para rolagem e arraste. Use implementações do Lodash armazenadas em referências e sempre cancele-as quando o componente for desmontado.