Como acabamos de falar sobre eventos, agora é um bom momento para mencionar eventos personalizados. Todos os eventos sobre os quais falamos até agora são eventos “reais”, por assim dizer. Eventos que se originam no DOM com base em coisas reais que acontecem, como um clique ou pressionamento de tecla. Esses eventos podem ser “disparados” artificialmente no jQuery. Por exemplo, para “fingir” um clique em um botão, você pode fazer:
$("#some-button").trigger("click");Então, qualquer manipulador de cliques vinculado a esse botão será acionado como se um usuário realmente tivesse clicado naquele botão. Mas e se fizéssemos:
$("#some-button").trigger("dance");O que acontece depois? “Dançar” não é um evento “real”. Mas nenhum erro será lançado. Acontece que provavelmente não há nenhum manipulador de “dança” vinculado a esse botão. Mas pode haver e isso é essencialmente o que um evento personalizado é. Um evento com um nome que você acabou de inventar.
Por que você faria isso? Principalmente por motivos organizacionais. Talvez você goste de separar seu JavaScript que trata de eventos e ações e seu JavaScript que trata de dados e coisas administrativas. Isso é muito razoável. Se este botão fosse talvez um botão “Salvar configurações”, você poderia simplesmente disparar um evento personalizado denominado “salvar-configurações” e, em outro lugar, ter um manipulador que espera o evento disparar e salva os dados. Isso é essencialmente o que fizemos no exemplo do vídeo.
Outro caso de uso para eventos personalizados é a criação de componentes de UI genéricos. Eu falo sobre isso nesta postagem do blog.
Talvez você esteja criando um efeito sanfona como um componente de IU. O acordeão faz o que todos os acordeões fazem, abre e fecha os painéis com cliques / torneiras. Seu componente de IU faz isso muito bem. Agora, um desenvolvedor que usa esse acordeão pode ter coisas especiais e exclusivas que deseja que aconteçam com ele. Digamos que eles estejam usando o acordeão para configurações de conta e, quando um usuário fecha um painel, ele deseja salvar os dados dos elementos de formulário desse painel. Um modelo tradicional pode ser para o autor desse componente de UI de acordeão oferecer funções de retorno de chamada quando essa ação acontecer. Ao inicializar o acordeão, você passa as funções de retorno de chamada que deseja chamar quando essas coisas acontecerem. Esse é um caminho a percorrer. Outro caminho seria o acordeão disparar automaticamente eventos personalizados para todas as ações relevantes que realiza.Quando esse painel fecha, ele pode disparar umpanelClosedevento no próprio elemento de acordeão. Então, os desenvolvedores que trabalham com ele podem apenas se vincular a esses eventos. É apenas mais um caminho que você pode seguir por motivos de organização que podem ser bastante elegantes.