📖프레임워크 없는 프론트 개발을 읽고 - 3장. DOM 이벤트 관리

MJ·2023년 1월 4일

DOM 이벤트 책을 읽고

책을 읽고

목록 보기

3/5

웹 프론트엔드 개발자로 성장하기 위해 우테코에서 추천받은 책을 읽고

✔️ 이벤트?

웹 애플리케이션은 고정된 그림이 아니다. 애플리케이션의 내용은 시간이 지남에 따라 변경된다. 이런 변경을 만드는 것이 이벤트다.

✔️ YAGNI 원칙

YAGNI 원칙이란 You aren't gonna need it의 약자로 정말 필요하다고 간주할 때까지 기능을 추가하지 마라라는 원칙이다.

한마디로 미래를 예측하지마라라는 이야기다.

프로젝트를 접근할 때, 먼저 가장 중요한 기능에 초점을 맞춰 개발하고 새로운 요구가 생길면 이에 따라 아키텍처를 지속적으로 발전시켜 가야한다.

당신이 필요하다고 예측할 때가 아니라 실제로 필요할 때 구현하라.
-제프리스(xp의 창시자)

특히 프레임워크 없는 프로젝트에서는 이 원칙은 절대적으로 중요하게 여겨진다.
아키텍처를 과도하게 엔지니어링할 경우 아무도 유지 관리하지 않는 또 다른 프레임워크를 작성하게 되면 확장 설계에 과도한 위험이 따르기 때문이다.

✔️ DOM 이벤트 API

이벤트는 웹 애플리케이션에서 발생하는 동작으로, 브라우저는 사용자에게 이를 알려줘 어떤 방식으로든 반응할 수 있다.

마우스 이벤트, 키보드 이벤트, 뷰 이벤트를 포함한 사용자가 트리거한 이벤트에 반응할 수 있고, 시스템 자체에서도 이벤트를 생성할 수 있다.

기본 클릭 이벤트 라이프 사이클이다.

버튼 렌더링 🔜 버튼 클릭 🔜 click 이벤트 전달 🔜 click 이벤트 캡처 🔜 click 이벤트에 반응

❗ 이벤트에 반응하려면 이벤트를 트리거한 DOM요소(이벤트 핸들러로 불리는 콜백)에 연결해야한다.

❗ 뷰나 시스템 이벤트의 경우 window 객체에 이벤트 핸드러를 연결해야 한다.

속성에 핸들러 연결

on속성

이벤트 핸들러를 DOM요소에 연결하는 방법에 빠르지만 지저분한 방법으로 on속성을 사용하는 방법이 있다.
모든 이벤트 타입마다 DOM요소에 해당되는 속성을 가진다.

on속성의 단점은 속성을 사용하게되면 한번에 하나의 핸들러만 연결이 가능하기 때문이다. 코드가 핸드러를 덮어 쓰면 원래 핸들러는 영원히 소실된다.

addEventListener로 핸들러 연결

이를 해결하기 위해 더 나은 접근 방식인 addEventListener 메서드가 있다.
이 메서드는 이벤트를 처리하는 모든 DOM노드에 EventTarget 인터페이스를 구현한다.
인터페이스의 add~메서드는 이벤트 핸드러를 DOM 노드에 추가한다.

removeEventListener로 이벤트 리스너 삭제

DOM에 요소가 더 이상 존재하지 않으면 메모리 누수가 발생한다.
이를 방지하고자 해당 메서드를 사용하여 메모리 누수를 방지할 수 있다.

이벤트 객체

웹 애플리케이션에 전달된 모든 이벤트에는 Event 인터페이스를 구현한다. 타입에 따라 이벤트 객체는 Event 인터페이스를 확장하는 구체적인 Event 인터페이스를 구현할 수 있다.

예시로 click이벤트는 MouseEvent 인터페이스를 구현한다.
이 인터페이스에는 이벤트 중 포인터의 좌표, 이동.. 에 대한 정보등이 있다.
- MouseEvnet의 인터페이스 계층 구조

DOM 이벤트 라이프사이클

여기 중첩된 HTML 구조가 있다.

<body>
  <div>
    <button/>
  </div>
<body>

document
  .querySelector('div')
  .addEventListener('click', () => { // click은 첫번째 매개 변수로 이벤트의 타입
    console.log('Div Click') // {}안에 코드는 두번째 매개 변수로 이벤트 핸들러
  }, false) // false는 세번째 매개 변수로 useCapture이다.

document
  .querySelector('button')
  .addEventListener('click', () => {
  	console.log('Button Click')
  }, false)

이 구조는 버튼을 클릭했을 때 button이 div안에 있으므로 button부터 시작해 두 핸들러가 모두 호출된다. 이벤트 객체는 이를 트리거한 DOM 노트에서 시작해 모든 조상 노드로 올라간다.

이 메커니즘을 버블단계 or 이벤트 버블링이라 불린다.
이 단계는 핸들러가 상향식으로 처리된다.

이를 해결하는 방법은 Event 인터페이스의 stopPropagation메서드를 사용해 버블 체인을 중지할 수 있다.

addEventListener메서드에 세 번째 매개변수는 useCapture라고 불리며 기본값이 false인 값이 있다. 이 매개변수는 선택 사항이지만 폭넓은 브라우저 호환성을 갖기 위해서는 포함시켜야한다.

이 매개변수에 true를 사용하게 되면 버블단계 대신 캡처 단계에 이벤트 핸들러가 추가한다는 것을 의미한다.
캡처 단계는 핸들러가 버블단계에 반대인 하향식으로 처리된다.

시스템은 캡처단계와🔜 목표단계를 거쳐🔜 버블단계로 실행된다.

캡처단계: 이벤트가 html에서 목표 요소로 이동한다.
목표단계: 이벤트가 목표 요소에 도달한다.
버블단계: 이벤트가 목표 요소에서 html로 이동한다.

기본 이벤트 처리 아키텍처

새로운 상태마다 새로운 DOM트리를 생성해 가상 DOM알고리즘을 적용시킬 수 있다.모든 이벤트 다음에 상태를 조작한 후 새로운 상태로 메인 렌더링 함수를 호출한다.

초기상태 🔜 랜더링 🔜 이벤트 🔜 새로운 상태 🔜 랜더링 🔜 이벤트 🔜 새로운상태 🔜 랜더링 🔜 ...

사용자가 항목을 추가하고 삭제하는 것을 가정한다.

초기상태: 비어있는 요소
렌더링: 사용자에게 비어있는 요소 표시
이벤트: 사용자가 '더미'라는 새 항목 생성
새로운 상태: 하나의 항목을 가진 요소
렌더링: 사용자에게 하나의 항목을 가진 요소 표시
이벤트: 사용자가 항목 삭제
새로운 상태: 비어있는 요소
렌더링: 비어있는 요소 표시

애플리케이션의 간단한 유스케이스의 단계를 열거함으로써 상태-렌더링-이벤트 루프에대해 알아보았다.

A fancy web like a rose

이전 포스트

📖프레임워크 없는 프론트 개발을 읽고 - 2장. 랜더링

다음 포스트