이벤트 위임에 대해 알기 전 우선 이벤트와 이벤트 핸들러에 대해 알고 가자.

이벤트와 이벤트 핸들러

브라우저는 사용자가 어떤 행동을 하였을 때, 이를 감지하여 이벤트를 발생시킨다.

ex) 참된 개발자: 브라우저야 사용자가 제출하기 버튼을 클릭 했을 때, 정보를 제출하는 함수를 호출(실행)해줘~

이 때 사용자가 언제 행동을 할지 모르기 때문에 개발자는 브라우저에게 대신 함수를 호출해달라고 한다.

이벤트 발생 시 호출할 함수를 이벤트 핸들러라고 한다.

• 이벤트 발생 시 호출될 함수: 이벤트 핸들러
• 이벤트 발생 시 브라우저에게 이벤트 핸들러 호출을 위임: 이벤트 핸들러 등록
• 이벤트 핸들러를 등록하는 방법은 여러가지가 있는데 설명을 위해 이번 장에서는 이벤트 리스너 방식을 사용하겠습니다.

이벤트 위임

이벤트 위임은 이벤트 리스너를 하위 요소에 추가하는 대신 상위 요소에 추가하여 이벤트를 위임하는 것을 말한다.

이벤트 리스너는 이벤트 버블링(Event Bubbling)으로 인해 하위 요소에서 이벤트가 발생할 때 마다 이벤트 리스너가 실행된다.

아래 그림은 이벤트 전파가 일어나는 흐름을 설명한 그림이다. 이벤트 전파에 대한 설명은 그림으로 대체한다.

이벤트 위임을 사용하는 이유

이벤트 위임을 사용하면 하위 요소에 같은 동작을 하는 이벤트를 중복해서 등록해주지 않고 상위 요소에 이벤트 위임을 통해 등록하여 중복을 피하고 불필요한 메모리 낭비를 줄일 수 있다.

또한, 제거된 요소에 이벤트를 해제하고 새 요소에 이벤트를 다시 등록하는 번거로운 작업을 할 필요가 없어지므로 적절한 상황에 맞게 유용하게 사용할 수 있다.

댓글 공유

📌 모의 면접 회고

HTML 수업 때 데레사 강사님께 기술면접을 1:1로 본 이후로 오래간만에 모의 면접을 보게되었다.

박신영 강사님께서 인성면접을, 다른 수강생은 기술면접을 면접관 입장이 되어 나에게 질문해주었다.

1. 😃 인성 면접

어떤 개발자가 되길 원하는가?, 프로젝트 및 협업 과정에서 어떤 갈등을 겪었고 어떻게 해결하였는지 등 개발자로서 어떤 마인드를 가지고 있고 어떤 사람인지 판단할 수 있을 만한 질문들이었다.

모든 질문에 어떻게 답변했는지는 기억나지 않지만 피드백을 받은 것을 이야기해보자면,

👍 좋았던 점

1. 시작할 때 웃는 모습이 좋은 사람이라는 인상을 주고 마음을 편안하게 해주어 좋았다.
2. 커뮤니케이션과 협업을 일관되게 강조하고 중요시하고 있다는 점이 좋았다.
3. 말의 끝맺음을 제대로 하여 듣는 사람 입장에서 좋았다.
   • 추가로 대화에서, 개발에서 정리를 잘하는 사람인데 이 부분으로 어필할 수 있으면 더욱 좋을듯!
4. Why? 에 대해 생각하는 사람으로 느껴져서 좋았다.
5. 약점에 대해서 스스로 대안이 있어서 인상적이었다.

💦 아쉬운 점

1. 의견, 주장이 강해보여 의견 충돌 시 강한 타입처럼 느껴질 수 있을 것 같아보인다.
2. 어떤 개발자가 되고 싶냐는 질문에 좀 더 직무, 역량 관점에서 답변할 수 있으면 좋을 것 같다.
3. 면접볼 때는 흔들의자에 앉지 말고 고정된 의자에 앉도록 하자.
4. 개발자로서 역량 설명할 때 커뮤니케이션 부분에서 누구와 협업을 하는지에 대해서도 간략하게 짚고 넘어갔으면 좋았을 것 같다.
5. 협업 경험에 대해 설명할 때, 부정적인 얘기를 했던게 기억에 남을 것 같다. 이 부분을 나의 약점을 잘 살려냈던 것처럼 풀어나가보면 좋을 것 같다.
6. 신입,주니어 라는 용어 사용 금지

2. 🛠 기술 면접

기술면접은 프로젝트 경험에 대해 질문해주셨고 기술적으로 깊은 고민을 해본 적이 있는지, 면접자가 기술에 사용 이유와 원리를 알고 사용하는 것인지 확인하는 질문들이었다.

👍 좋았던 점

1. 페어프로그래밍을 통해 기술적인 단계를 깊이있게 공부하고 블로그에 정리해두었다는 점이 인상깊었다.
2. 기술 블로그에 대해 피드백을 받고 개선한다는 부분을 차별점으로 어필하는 모습 좋았다.

💦 아쉬운 점

1. 전반적으로 기술적인 답변이 제대로 나오지 않아 아쉬웠다.
2. CBD 라이브러리를 만들었다고 할 때 정확히 어떤 부분까지 만들어보았는지 자세한 설명이 부족했다.
3. 회피와 타협이라는 부정적인 단어 사용이 잦아서 아쉬웠다.
   • 부정적인 단어 대신 “라이브러리를 고치는 것은 비용이 많이 드는 작업이어서 프로젝트 기간에는 해당 부분을 이런 식으로 구현하여 해결하였다”로 사용해보자.
4. 트러블 슈팅 질문에 대한 답변이 기술적인 이슈 해결이 아닌 다른 답변이 나와서 아쉬웠다.
   • 트러블 슈팅 질문에 대한 소스들을 미리 준비해두면 도움이 될 것 같다.
5. 리팩터링 질문이 나왔을 때, 너무 협업에만 집중해서 이야기한 것이 아쉽다. 그렇다면 성능 개선, 최적화 등에 대한 고민을 하지 않는 것처럼 보여서 아쉬웠다.

댓글 공유