Por algum motivo atualmente é convenção nomear qualquer método com o prefixo handle
quando ele é chamado em um evento, tipo chamar de handleClick
um método chamado num evento de click, handleChange
quando lidamos com o evento change e assim por diante.
Mas advinha?! Isso é o crime do crime!
O nomes dos nossos métodos ficam sem significado, o nome não diz nada sobre a função do método, só é dito quando ele é disparado, não o que ele de fato faz!
Suponhamos que temos que trabalhar em uma loja de roupas e precisamos dar manutenção neste componente, o que acontece quando clico nos botões?
function MyComponent() {
/.../
return (
<>
<button name="short" onClick={handleClick}> Short </button>
<button name="medium" onClick={handleClick}> Medium </button>
<button name="big" onClick={handleClick}> Big </button>
<button name="bigger" onClick={handleClick}> Bigger </button>
</>
)
}
Teria que ler a implementação do handleClick
pra poder responder essa pergunta, apenas com a informação atual o máximo que podemos fazer é supor de forma bem branda o que acontece ao clicar no botão, mas não temos quase nenhuma certeza!
Mas fazendo apenas ajustando o nome da função, fica claro o que acontece ao clicar no botão
function MyComponent() {
/.../
return (
<>
<button name="short" onClick={applySearchFilter}> Short </button>
<button name="medium" onClick={applySearchFilter}> Medium </button>
<button name="big" onClick={applySearchFilter}> Big </button>
<button name="bigger" onClick={applySearchFilter}> Bigger </button>
</>
)
}
Com uma simples alteração no nome da função e apenas lendo o return
do componente podemos saber o que está acontecendo, sem precisar ir na função, entender a lógica lá pra poder saber o que acontece. O código está claro quanto ao que ele faz, é explícito como deve ser.
📝 Note
Existe apenas um caso que faz algum sentido chamar a função handler de handle
, e é quando, em casos muito raros, a função precisa fazer mais de uma coisa. Nesse caso chamar de handle
é o meio genérico de chamar o método e, dentro dele, chamamos os 2 ou mais métodos necessários.
Por exemplo, suponhamos que o pessoal de produto acordou, caiu da cama, bateu a cabeça no chão e quer que quando o usuário mudar o filtro de busca o site mude de cor completamente, ai faz sentido usar handleClick
function MyComponent() {
function handleClick(e) {
applySearchFilter(e);
changeSiteColor(e);
}
return (
<>
<button name="short" onClick={handleClick}> Short </button>
<button name="medium" onClick={handleClick}> Medium </button>
<button name="big" onClick={handleClick}> Big </button>
<button name="bigger" onClick={handleClick}> Bigger </button>
</>
)
}
E se nomearem a função de forma errada?
Esse tipo de coisa precisa ser percebida e corrigida o quanto antes, se essa má nomeação te levou ao erro, você tem o dever de ajustar o nome da função para prevenir que futuros devs sejam induzidos ao erro também!
É legal também tirar print do git blame e colocar no grupo da empresa
Reutilização legível
Usando esse método de nomenclatura ainda por cima ganhamos a semântica de poder reutilizar a função usada no evento mantendo a leitura do código limpa!
Suponhamos que nos exemplos anteriores, por algum motivo, outro método precisa chamar a função applySearchFilter
function MyComponent() {
function applySearchFilter(e) { /.../ }
function updateSearchText(e) {
applySearchFilter(e);
}
return (
<>
/.../
<button name="short" onClick={applySearchFilter}> Short </button>
<button name="medium" onClick={applySearchFilter}> Medium </button>
<button name="big" onClick={applySearchFilter}> Big </button>
<button name="bigger" onClick={applySearchFilter}> Bigger </button>
</>
)
}
Dessa forma podemos ler de forma falada dizendo que "após atualizar o texto de busca o filtro é aplicado" ao invés de dizer "após atualizar o texto de busca lidamos com o click"
Tem uma fala de Grady Booch que eu gosto muito
Um código limpo é simples e direto. Ele é tão bem legível como uma prosa bem escrita.
💡 Tips
- Pra nomear uma função sempre se pergunte: "O que essa função faz?"
📚 References
Vozes da minha cabeça
Clean Code - Uncle Bob
Top comments (0)