Q. 타입스크립트를 사용해본 적이 있나요? 어떤지 말씀해주세요
A. 간단한 실습에서 사용해본 적이 있다. 자바스크립트는 런타임에서 오류를 발견하는 반면 타입스크립트는 컴파일 단계에서 발견할 수 있는 장점이 있었다.
-
장점: 명시적으로 정적 타입을 지정해서 개발자의 의도를 명확하게 코드로 기술할 수 있게 해준다.
코드의 예측가능성을 높여서 디버깅을 쉽게 할 수 있다.
코드 자동완성이나 실행 전 피드백으로 작업과 동시에 디버깅이 가능해 생산성을 높일 수 있다.
코드 작성 단계에서 타입을 체크해 오류를 확인할 수 있다.
미리 타입을 결정하기 때문에 실행 속도가 매우 빠르다. -
단점: 코드 작성 시 매번 개발자가 타입을 지정해줘야 하기 때문에 번거롭다.
코드량이 증가하고 컴파일 시간이 오래 걸린다.
Q. Virtual DOM에 대해 아는 것을 말해주세요 (개념, 원리 등등)
A. 실제 DOM이 아닌 가상의 DOM을 만들어서 DOM 조작을 가상적으로 렌더링해본 뒤 실제 DOM과 차이나는 부분만 리렌더링하기 위해 사용되는 것
Virtual DOM (VDOM)은 UI의 이상적인 또는 “가상”적인 표현을 메모리에 저장하고 ReactDOM과 같은 라이브러리에 의해 “실제” DOM과 동기화하는 프로그래밍 개념입니다.
- by. 리액트 공식 문서 reactjs.org
Virtual DOM은 SPA의 특징으로 인해 DOM의 복잡도가 증가하여 DOM을 직접적으로 조작하면 브라우저 렌더링을 자주 하게되고, PC 자원의 소모가 커져 이를 해결하기 위해 DOM을 추상화 한 것이다.
[이미지 출처] https://saiki.hashnode.dev/the-one-thing-that-no-one-properly-explains-about-react-why-virtual-dom
DOM을 조작하면 브라우저의 동작원리인 <HTML/CSS 파싱→DOM/CSSOM 트리 생성→attachment→렌더링 트리 생성→레이아웃(=리플로우)→페인팅>에서 렌더 트리 생성, 레이아웃, 페인팅을 다시 진행한다.
Virtual DOM은 단순하게 DOM을 이중 버퍼링하는 개념이다. (이중 버퍼링은 컴퓨터그래픽 부문에서 활용되는 방법으로, 기존 화면에 새로운 이미지를 그리면 이미지가 그려지는 동안 화면이 깜빡거리는 현상이 일어나므로 보이지 않는 화면에 이미지를 그린 뒤 완성되고 나면 완성된 화면으로 전환하는 기법이다.)
변화가 일어나면 모든 변화를 따로따로 오프라인 DOM 트리를 변경한다. 오프라인 DOM 트리는 렌더링이 되지 않기 때문에 변경하는 비용이 적게 든다. 그 다음 이 모든 오프라인 DOM 트리의 변경사항을 모두 합쳐 실제 DOM 트리에 한번에 업데이트 하는 것이다. 연산의 양은 많아지지만 횟수가 딱 한 번 이기 때문에 더 효과적이다.
Virtual DOM 없이도 이 과정을 행할 수는 있지만, 관리를 수월하게 하게 위해 자동화해주는 역할이 Virtual DOM이다.
Q. props와 state에 대해 설명해주세요
A. props는 함수가 매개변수를 넘겨받는 것과 비슷하게, 상위 컴포넌트로부터 넘겨받는 변수로, 넘겨받은 컴포넌트 내부에서는 불변하다. state는 값이 변화할 때 컴포넌트를 리렌더링하기 위해 정하는 변수로, setState로 변경할 수 있다.
props와 state는 일반 JavaScript 객체입니다. 두 객체 모두 렌더링 결과물에 영향을 주는 정보를 갖고 있는데, 한 가지 중요한 방식에서 차이가 있습니다. props는 (함수 매개변수처럼) 컴포넌트에 전달되는 반면 state는 (함수 내에 선언된 변수처럼) 컴포넌트 안에서
관리됩니다. -by. 리액트 공식 문서 reactjs.org
-
props: 컴포넌트의 환경변수로, 필요하면 넣는 옵션이다. 부모로부터 전달 받으며, 받고 나서는 immutable하다.
컴포넌트가 자신의 props를 변경할 수는 없지만 자식 컴포넌트의 props를 합치는 것에 대한 권한은 있다. -
state: 컴포넌트가 마운트될 때 기본값으로 시작하며, 시간에 따라 변화한다(주로 유저 이벤트가 일어날 때).
state는 스냅샷, 즉, 어느 시점의 serializable(직렬화, 객체를 다른 환경에서 사용하기 위해 데이터화하는 것)한 표현이다.
컴포넌트는 자신의 state를 내부적으로 관리하지만, state 초기값을 설정하는 것 외에 자식 컴포넌트의 state에는 관심이 없다. 따라서 state를 private하다고 할 수 있다.
| props | state | |
|---|---|---|
| 부모로부터 초기값을 가져올 수 있는가? | O | O |
| 부모 컴포넌트에 의해 변경될 수 있는가? | O | X |
| 컴포넌트 내부에서 기본값을 설정할 수 있는가? | O | O |
| 컴포넌트 내부에서 변경할 수 있는가? | X | O |
| 자식 컴포넌트의 초기값을 설정할 수 있는가? | O | O |
| 자식 컴포넌트 내부에서 변경할 수 있는가? | O | X |
※ props는 serializable하다고 하지 않았는데, 왜냐하면 props로 콜백함수를 전달하는 일이 빈번하기 때문이다. 또한 props와 state 모두 부모로부터 받은 초기값이 컴포넌트 내부에서 정의한 기본값보다 우선된다.
그래서 언제 props를 사용하고 언제 state를 사용해야 할까?
→ 컴포넌트가 렌더링 간에 차이를 추적해야 하면 state, 아니면 기본적으로 props를 사용하자.
컴포넌트에 state가 꼭 있어야 할까?
→ 없어도 된다. 애초에 state는 복잡도를 증가시키고 예측가능성을 감소시키므로 state 없는 컴포넌트가 권장된다. 사용자와 상호작용하는 앱이라서 state 없이는 불가능하더라도, 너무 많은 stateful 컴포넌트(props와 state를 모두 가진 컴포넌트)는 지양해야 한다.
