Entrar Ainda não tem acesso?
Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Diferença entre o addEventListener na table e no tr, na remoção de "novos" pacientes (adicionados através do formulário)

Referente ao curso JavaScript: programando na linguagem da web, no capítulo Remoção, Delegação e Animação e atividade Delegando eventos

por Estudante
| 258k xp | 263 posts

Olá pessoal!

Favor me retornem se entendi corretamente os dois itens abaixo:

  • quando o addEventListener é considerado na <tr>, o evento não é acionado para novos pacientes (adicionados pelo formulário), porque o código do arquivo javascript é interpretado (digamos "compilado") apenas no carregamento da página (e, desta forma, apenas os pacientes/linhas/<tr>s do DOM que já estão na página recebem o evento) (além disso, nas próximas vezes que esse código JS for chamado, ele não será mais interpretado, mas somente "executado"):
var pacientes = document.querySelectorAll(".paciente");

pacientes.forEach(function(paciente) {
    paciente.addEventListener("dblclick", function() {
        this.remove();
    });
});
  • quando o addEventListener é considerado na <table>, o evento é acionado para novos pacientes (adicionados pelo formulário), porque, ao contrário do arquivo javascript, a cada adição de paciente o DOM é sempre atualizado, por isso o evento na <table> consegue reconhecer ações nas colunas de pacientes novos:
var tabela = document.querySelector("table");

tabela.addEventListener("dblclick",function(event){
    event.target.parentNode.remove();
});
4 respostas
solução!
por Paulo Scalercio
| 363.3k xp | 341 posts
Instrutor Instrutor & Desenvolvedor

Oi Elias, tudo bom?

A sua primeira conclusão está correta, como utilizamos o querySelector para nos retornar uma lista com as tags TR e adicionamos um eventListener para cada, as novas inclusões através do formulário não terão esse "escutador" atrelado a elas, uma vez que o código da sua página não re-executado a cada inserção.

Concluindo, a iteração por essa lista adicionando os "escutadores" ocorre apenas uma vez, durante o carregamento da sua página.

Agora, no seu segundo ponto, temos algo um pouco diferente. No javascript temos um comportamento dos eventos que chamamos de event bubbling.

Event Bubbling

Todo evento tende a "borbulhar" pelas tags do seu documento, até que o mesmo "saia" do documento pela tag html. Imagine um copo de refrigerante sendo seu documento e as bolhas sendo os eventos. Os eventos vão subindo na hierarquia até "deixarem o documento pelo topo"

Então vamos lá, vamos imaginar o seguinte cenário:

<div id="1">
    <div id="2">
        <div id ="3">
        </div>
    </div>
</div>

No exemplo acima, temos 3 divs aninhadas, vamos usá-las para simular esse event bubbling.

Nesse cenário, se eu disparo algum evento (click por exemplo), na div com id 3 , esse evento borbulhará pela div 2 e depois pela div 1.

Se eu disparo algum evento na div 2, esse evento borbulhará apenas pela div 1,

Agora se eu disparo esse evento na div 1, só ela saberá da ocorrência desse evento.

Qual a conclusão podemos tirar desse fato?

Então, eventos disparados em elementos mais internos, são "escutados" pelos elementos mais acima no nível hierarquico!

Agora sabemos que além do próprio elemento que sofre a ação, os pais também podem ouvir esses eventos.

Após toda essa explicação (espero que não tenha ficado cansativa <3) vamos para o seu cenário.

Sabemos que nessa tag table estarão todos os pacientes listados e além disso, nós sabemos que eventos que ocorrem dentro dessa table, nos seus filhos, ela também escutará.

Com essa ideia em mente e sabendo do event bubbling eu posso adicionar um escutado de evento nessa tag mais externa e quando esse evento ocorrer eu executo a lógica no alvo dessa ação (event.target)!

A diferença não é que o dom foi atualizado, ele realmente foi, mas a sacada é que quem está escutando o evento agora é a table! Então mesmo que esse elemento seja inserido depois, a table saberá lidar com essa ação!

Um ponto interessante de se falar também é que podemos adicionar esse EventListener antes de colocarmos o elemento criado dentro da tag, tendo um EventListener por tr paciente. Porém é de facil percepção que essa não é uma implementação escalável, imagine se esse número de pacientes cresce absurdamente, teremos milhares de eventListeners!!!

Então, eu como desenvolvedor quero um código fácil de dar manutenção e além disso, quero que ele rode na velocidade da luz! Por isso a decisão de DELEGAR esse evento para a table, tendo apenas 1 escutador, isso é o que chamamos de delegação de eventos.

Elías, sei que escrevi muito mas prefiro dar informações completas hahahah

No mais, espero ter ajudado na sua jornada.

Um grande abraço e bons estudos!

por Estudante
| 258k xp | 263 posts

Olá Paulo, tudo bem e você?

Que nada, por mim pode continuar escrevendo bastante, a explicação está ótima, bem explícita e sem espaço para dúvidas.

Obrigado!

por Wanderson Macêdo
| 3966.1k xp | 8086 posts
Instrutor Desenvolvedor

Oi Elías, não sei se entendi bem, mas deixa eu tentar te explicar.

Quando você ouve o evento na linha (tr) as novas linhas não são consideradas por que o foreach adiciona o ouvinte de eventos ao carregar a página, depois disso ele não percorre as linhas novamente.

Quando ouvimos o evento da tabela (table) estamos usando uma técnica que permite ouvir os eventos acionados nos elementos filhos da tabela, ou seja, a tabela inteira e por isso conseguimos considerar as novas linhas.

Essa característica de poder capturar eventos nos elementos pai se deve ao Event Bubbling, os eventos são causados nos elementos, mas eles borbulham para os elementos pai onde podemos capturá-los e agir conforme queremos.

Fez sentido?

por Estudante
| 258k xp | 263 posts

Olá Wanderson,

Fez sentido sim, obrigado também pelo retorno!