3장 DOM 이벤트 관리
'애플리케이션의 내용은 시간이 지남에 따라 변한다. 이런 변경이 발생하게 만드는 것이 이벤트다.'
'어떻게 프레임워크 없이 애플리케이션에서 이런 이벤트를 관리할 수 있을까?'
키워드
야그니(yagni) 원칙
DOM 이벤트 API에 대하여…
앱에 이벤트 추가하기 - html 문자열 대신 템플릿 요소
앱에 이벤트 추가하기 - 이벤트 처리 아키텍쳐 정의 및 구현
앱에 이벤트 추가하기 - 이벤트 위임으로 개선
야그니(yagni) 원칙
가장 중요한 기능에 초점을 맞춰 개발하고, 새로운 요구가 생기면 이에 따라 아키텍쳐를 지속적으로 발전시켜나간다.
이 파트의 핵심은 다음 문장에서 가장 잘 드러난다.
당신이 필요하다고 예측할 때가 아니라 실제로 필요할 때 구현하라
나도 보통 이런 마인드로 개발을 하는 편이다. 특히 라이브러리를 직접 만들어보고 난 후로, 내가 현재 가장 최선이라고 생각되는 결정을 내리고(미래를 과하게 예견하는 게 아니라) 나중에 관련해서 문제가 발생했을 때 그때 개선을 해본다.
DOM 이벤트 API에 대하여…
핸들러 연결 하는법, 이벤트 객체, 이벤트 라이프 사이클, 사용자 정의 이벤트 등 기본 개념에 대한 설명이 주를 이루고 있다.
앱에 이벤트 추가하기 - html 문자열 대신 템플릿 요소
기존 문자열을 사용한 방식으로는, 문자열에 이벤트를 등록할 수 없기 때문에, DOM 노드를 사용해야한다. 여러 방법이 있지만, 여기서는 template를 사용해 요소 안에 마크업을 유지하는 것이다. template은 렌더링 엔진의 스탬프로 사용할 수 있는 보이지 않는 태그다. 필요한 구성요소들을 작성하고, 이들을 template에 감싼다.
앱에 이벤트 추가하기 - 이벤트 처리 아키텍쳐 정의 및 구현
이벤트 처리 아키텍쳐의 흐름은 이렇게 가져간다. 초기 상태 - 렌더링 - 이벤트로 인한 상태 변화 - 렌더링 ....
이에 맞춰 구현할 수 있도록한다.
앱에 이벤트 추가하기 - 이벤트 위임으로 개선
어느정도 초기 코드가 완성이 되었는데, 리스트에 모든 요소에 이벤트 핸들러가 연결이 되어있다면 이 부분에서 상당히 불편함을 느낄 수도 있다. 아이템 하나하나가 아니라 리스트에만 이벤트를 걸게끔 해서 작동시킬 수 있는데 이게 이벤트위임 방식이다. 이것으로 성능과 메모리 사용성을 개선시킬 수 있다.
여기서 유용하게 사용해볼 수 있는게 'matchs API'다. 요소가 실제 이벤트 대상인지 확인하는데 사용한다. 이 접근 방식을 사용하면 웹 페이지의 본문에서 하나의 이벤트 핸들러만 사용할 수 있다. 즉, 이벤트위임 라이브러리를 구축하는 것이다. (ex: gator.js)
그러나 yagni 원칙을 기억하라...실제로 필요할 때 까지는 이벤트 위임같은 최적화를 추가하지 말도록.
4장 웹 구성 요소
그냥 네이티브 API만으로도 컴포넌트라고 불리우는 것들을 구현할 수 있다. 이것은 웹 컴포넌트라고 불린다.
키워드
웹 구성 요소의 API
브라우저 지원현황
사용자 정의 요소 사용법(속성 관리, 라이프 사이클, 가상 DOM과의 통합, 사용자 정의 이벤트 연결 등등)
앱에 웹구성요소 사용
웹 구성 요소 vs 렌더링 함수
웹 구성 요소가 불러일으킨 사라지는 프레임워크에 대하여
웹 구성 요소의 API
세가지 중요 기술이 있다. html template, 사용자 정의요소, 섀도우 DOM...
섀도우돔과 가상돔이 헷갈릴 수 있는데, 가상돔은 성능과 관련된 문제를 해결하는 반면 섀도우돔은 그림자처럼, 섀도우돔 내부에 있는 것들은 전부 외부에 있는 돔의 맥락으로부터 완전히 격리시킬 수 있는 기술인듯하다.
브라우저 지원현황
너무 옛날 브라우저를 쓰는 경우가 아니라면 대부분 사용할 수 있다.
사용자 정의 요소 사용법(속성 관리, 라이프 사이클, 가상 DOM과의 통합, 사용자 정의 이벤트 연결 등등)
유스케이스들을 살펴보며, 사용자 정의 웹 컴포넌트를 어떻게 사용하는지 알아보는 챕터이다. 사용자 정의 이벤트와 엮어서 쓰는 것도 가능한테, 이에 대한 상세한 시나리오에 대해서도 알려주고 있다.
앱에 웹구성요소 사용
웹 구성요소와 커스텀 이벤트를 엮어 여태 만든 앱의 구조에 이를 적용하는 챕터이다.
웹 구성 요소 vs 렌더링 함수
웹 구성 요소를 사용하여 렌더링하는게 좋을까, 3장 까지의 함수를 이용한 접근 방식을 쓰는 게 좋을까?
둘다 여러가지 장단점이 있기 때문에, 상황에 맞게 쓰는게 좋을 듯 하다.
웹 구성 요소가 불러일으킨 사라지는 프레임워크에 대하여
사라지는 프레임워크: 코드를 작성하는 시점에서느 다른 프레임워크와 마찬가지로 동일하게 코드를 작성하지만, 제품 번들을 제작할 때 출력은 표준 웹 구성요소가 된다. 즉, 컴파일 타임에 프레임워크는 사라져버린다.
그런데 이렇게 된다면, 꽤 많은 상황에서 이러한 유형의 프레임워크가 리액트보다 빠를 것으로 생각된다.
가장 유명한 것 중에는 스벨트가 있다. (나도 스벨트....공부해보고 싶었는데.)
