# 워밍업
- doctype이란 무엇인가.
document type의 약자이다.
흔히 줄여서 DTD (document type definition) 이라고 불린다.
html이 어떤 버전으로 작성되었는지 미리 선언하여, 웹 브라우저가 내용을 올바르게 표시할 수 있도록 하는 것이 DTD이다.
즉, 어떤 html을 사용해서 문서를 사용할 것인지에 대해 브라우저에게 알려주는 역할.
(브라우저! 미리 알려줄게! 나는 이 HTML을 사용할 거야!)
- DTD의 종류는?
1) strict DTD (엄격)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
: 가장 표준이 되는 DTD이다.
: 확장 attr를 허용하지 않는다.
ex) font에 color, bgcolor등의 속성을 넣는 것을 허용하지 않는다는 뜻.
: W3C가 스타일 시트 사용을 장려하기 위해 만든 문서 타입이다. 제작자는 가능하면 strict 타입을 사용해야 한다고 한다.
2) transitional DTD (호환)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
: 일반적으로 가장 많이 쓰이는 DTD이다.
: 확장된 attr을 호환한다.
: strict 보다 로딩 속도가 느리다.
: strict 보다 표준에 가깝지는 않다.
: 과거의 모든 문서들을 strict DTD에 맞게 바꾸려면 엄청난 비용이 소모되므로, 그 중간 단계로 transitional DTD를 설정해놓은 것이다.
: 즉, strict 타입이 불가피하게 표현을 담당하는 속성이 필요한 경우에는 transitional DTD를 사용하고, 그 외에는 strict를 권장한다.
3) Frameset DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
: transitional DTD 위에 프레임 지원을 위한 태그와 속성을 추가한 문서 타입이다.
: 문서 구조화에 있어서는 transitional DTD와 같다.
# 이벤트 위임
- 이벤트 위임이란 무엇인가요?
: 이벤트 위임은 이벤트 리스너를 하위 요소에 추가하지 않고, 상위 요소에 추가하여, 하위 요소의 이벤트를 제어하는 기법이다.
-> 리스너는 DOM 이벤트 버블링으로 인해 하위 요소에서 이벤트가 발생될 때마다 실행된다.
[Q1] 자바스크립트에서 새로운 DOM요소가 계속 동적으로 생기는 상황이라면, 이벤트 위임을 활용하는 것이 좋을까요? 아니면 매번 이벤트리스너를 달아주는 것이 좋을까요?
=> 위임을 걸어주는것이 더 좋다. 각 하위 항목에 이벤트 핸들러를 연결하지 않고, 상위 요소에 하나의 단일 핸들러만 필요하기 때문에 메모리 사용 공간이 줄어든다. 제거된 요소에서 핸들러를 해제하고 새 요소에 대해 이벤트를 바인딩 할 필요가 없다.
- 이벤트 위임 과정은?
1) 컨테이너에 하나의 핸들러를 할당한다.
2) 핸들러의 event.target을 사용하여 이벤트가 발생한 요소가 어디인지 알아낸다.
3) 원하는 요소에서 이벤트가 발생했다고 확인되면 이벤트를 핸들링한다.
- 이벤트 위임의 장점은?
1) 각 하위 항목에 이벤트 핸들러를 연결하지 않고, 상위 요소에 하나의 단일 핸들러만 필요하기 때문에 메모리 사용 공간이 줄어든다.
2) 제거된 요소에서 핸들러를 해제하고 새 요소에 대해 이벤트를 바인딩 할 필요가 없다.
- 이벤트 위임의 단점은?
1) 이벤트 위임을 사용하려면, 반드시 이벤트가 버블링 되어야 한다.
근데 몇몇 이벤트는 버블링되지 않는다..! (focus, blur 같은 것들)
2) 낮은 레벨에 할당한 핸들러에는 event.stopPropagation()를 쓸 수 없다.
3) 컨테이너 수준에 할당된 핸들러가 응답할 필요가 있는 이벤트이든 아니든 상관없이, 모든 하위 컨테이너에서 발생하는 이벤트에 응답해야 하므로, CPU 작업 부하가 늘어날 수 있다. (근데 무시할만한 수준으로 실제로는 잘 고려하지 않는다.)
# 이벤트 버블링
- 이벤트 버블링이란?
: 이벤트 버블링은 특정 화면 요소에서 이벤트가 발생했을 때 해당 이벤트가 더 상위의 화면 요소들로 전달되어가는 특징을 의미한다.
(상위 화면 요소란? html 트리 구조상 상위에 있는 요소)
codepen.io/zereight/pen/zYNqVeQ
"Trigger Clicks all the way up".
[Q3] 버블링되는 focusin, focusout과 버블링 되지 않는 focus, blur는 각각 언제 사용하면 좋을까요?
질문에 언급되어 있듯이, focusin, focusout은 버블링을 발생시킨다.
반면에 focus, blur는 버블링을 발생시키지 않는다.
{focusin - focusout}, {focus - blur} 과 쌍으로 분류된다.
그러니까 input focus되거나 focus를 잃을때 부모요소에서 리스너를 동작시키고 싶으면 focusint, focusout을 사용하자~
[Q4] DOM Level0부터 있었던 onclick=handler와 같이 이벤트핸들러 attribute 방식보다 DOM Level2에 등장한 addEventListener을 사용하는 것이 항상 더 좋을까요?
항상은 아니다.
react를 보면 JSX 문법에서 onClick같은 이벤트에 바로 넣어주는 것을 심심치 않게 볼 수 있다.
onclick은 하나의 콜백만 지정할 수 있지만, addEventListener를 사용하면 여러개의 이벤트 리스너를 추가할 수 있다.
(onclick을 2번하면 덮어쓰게된다~ 이말이야)
근데 onclick은 왜있는거지? => addEventListener ie8 이하에서는 작동을 하지않기 때문에, 구형 브라우저 지원이 필요하면 onclick을 사용하거나 다른 방법을 찾아야한다~
# 이벤트 캡쳐링
- 이벤트 캡처링이란?
: 이벤트 캡처링은 이벤트 버블링과 반대 방향으로 진행되는 이벤트 전파 방식이다.
codepen.io/zereight/pen/vYgGoXm
이때에는 위 예제처럼 해당 이벤트를 감지하기 위해, 이벤트 버블링과 반대 방향으로 탐색한다.
# event.stopPropagation()
이 API는 해당 이벤트가 전파되는 것을 막는다.
이벤트 버블링의 경우에는 클릭한 요소의 이벤트만 발생시키고, 상위 요소로 이벤트를 전달하는 것을 방해한다.
이벤트 캡처링의 경우에는 클릭한 요소의 최상위 요소의 이벤트만 동작시키고, 하위 요소들로 이벤트를 전달하지 않는다.
#커스텀 이벤트
- 커스텀 이벤트는 사용자가 직접 이벤트를 정의하여 사용할 수 있게 할 수 있다.
[Q2] 키보드이벤트에서 keyup, keydown, keypress의 차이점이 있을까요? 있다면 각각 언제 활용하면 좋을까요?
key 이벤트 동작 순서는 다음과 같다.
keydown -> keypress -> keyup
예시를 들자면
1) 키보드를 누른다.
2) keydown 이벤트가 발생한다. (input text에는 아직 입력이 되지 않은 상태
3) input에 입력된다. keypress 이벤트가 발생한다.
4) 키보드에서 손을 뗀다. keyup 이벤트가 발생한다.
기능 정의
keydown: 키보드를 누를 때 실행, 계속 누르고 있는 경우에는 계속 실행됨
keypress: 키보드를 누를 때 실행, 게속 누르고 있는 경우에는 계속 실행됨.
keyup: 누른 키에서 손을 뗄 때 실행.
그럼 keydown, keypress가 같은가?
No, keypress는 '입력할 수 있는 키보드'를 눌렀을 때에만 반응한다.
예를들어서, 한글입력, 방향키, DELETE키와 같은 즉시 TEXT 입력이 반영되는 키보드가 아닌 것에는 반응하지 않는다.
반면에 keydown은 키보드의 어떤 키가 눌러지더라도 반응한다~
[Q1] Input에 change와 focusout 이벤트를 사용할 수 있는데 이 둘의 차이점이 무엇이고 어떤 것을 사용하는 것이 더 좋을까요?
change는 이벤트 요소 변경이 끝나면 발생하는 이벤트, 텍스트 입력 요소인 경우에는, 요소 변경이 끝날 떄가 아니고, 포커스를 잃을때 발생.
즉, 텍스트 입력 필드에 글자를 입력하는 동안엔 이벤트가 발생하지 않습니다. 하지만 버튼을 클릭하는 등의 동작을 통해 포커스를 다른 곳으로 옮기는 순간 change 이벤트가 발생.
select와 input type=checkbox,input type=radio같은 경우는 선택값이 변경된 직후에 이벤트가 발생.
change는 값이 변경되었고, 해당 객체에서 멀어져야 발생.
focusout은 그렇지 않다.
[Q2] 아무리 해도 removeEventListener가 동작하지 않았던 적이 있었습니다. 그래서 removeEventListener를 사용하기가 쉽지 않다는 것을 느꼈었는데요. removeEventListener를 잘 사용하는 방법을 공유해주세요!
callback함수를 익명함수로 줘서, addEventListener의 콜백함수와 주소값이 달랐거나, 둘 중 한곳에서 캡처링 설정이 되어있었던것 같은데요.
[Q3] input에서 keyup 이벤트를 사용했을 경우, 한글을 입력하고 엔터를 누르면 왜 두 번 호출되는지 설명해주세요.
IE에서는 정상인데 한글에서만 그렇죠
keyup, keydown에서 동일한 현상이 나타납니다.
keypress를 사용하면 정상이에요.
처럼 한글같은거를 입력할때는 아직 입력이 완성되지 않았다는 의미로 IME에서 컴포지션 상태가 되는데 이때 keycode 229를 보내어서 한번더 실행되게 됩니다.
Q5] 스크롤 이벤트의 경우에는 e.preventDefault를 사용할 일이 없을 것 같은데요.
그래서 스크롤 이벤트를 사용할 경우 { passive: true }로 preventDefault 호출 감시를 하지 않도록 구현하는 것을 많이 봤습니다.
preventDefault 호출이 필요없는 이벤트인 touch 이벤트는 { passive: true }가 default 값으로 설정되어 있는데 왜 스크롤 이벤트에는 { passive: true }가 default로 설정되어 있지 않는 것일까요? 감시해야 할 경우가 있는 것인가요?
addEventListener()의 첫번째 인자는 이벤트명이다.
2번째 인자는 콜백함수이다.
3번째함수는 EventListenerOptions이 들어간다.
option에는
{
capture
once
passive
signal
}
이 있다.
capture: true면 해당 이벤트를 캡처링 단계에서 수행한다. (이벤트 캡처링 적용 여부)
once: 이벤트를 한번만 호출하고 해제되는 옵션
passive: 스크롤 성능 향상을 위한 옵션으로, true일 경우, 스크롤을 위해서 블록되는 것을 방지한다. 이때에는 preventDefault를 사용할 수없다.
passive속성이 false이면 touchstart, touchmove와 같은 이벤트가 발생하면, preventDefault를 이용하여 실제 이벤트 자체를 막을 수 있어서 브라우저는 scroll 을 계속 할지/안할지를 매번 감시해야한다. (event.preventDefault가 호출되는 지에 대한 감시 비용을 줄인다.jbee.io/web/optimize-scroll-event/)
passive: true일 때에는 preventDefault를 이용하여 scroll 이벤트를 막지 않겠다고 브라우저에게 이야기하는 거랑 같다.
기본값은 false라서 기존 코드는 문제가 되지 않는다.
document.addEventListener나 body에 touchstart, touchmove같은 스크롤이 블록되는 이벤트인경우에 passive 기본 속성값은 true가 된다. (크롬 55+ 부터 지원)
amati.io/eventlisteneroptions-passive-true/
| touchstart | 스크린에 손가락이 닿을 때 발생한다 |
| touchmove | 스크린에 손가락이 닿은 채로 움직일 때 발생한다 |
'개발 > FrontEnd Interview' 카테고리의 다른 글
| 전역 변수를 지양해야하는 이유 (0) | 2021.03.29 |
|---|---|
| lexical scope 란? (0) | 2021.03.29 |
| 꼬리 호출 (0) | 2021.03.25 |
| 함수의 동작 방식 (0) | 2021.03.24 |
| 이벤트 루프란? (0) | 2021.03.21 |
