항해99 3주차 리액트 입문 전 알아야 할 기본 개념

*자바스크립트에서 유사배열과 배열의 차이는 무엇인가? 또한 유사배열의 각 요소를 수정하고 싶다면 어떤 과정을 거쳐야 하는가?

 

유사배열의 한 예시는 HTMLCollection Array 가 있다.

유사배열은 Array의 내장함수를 바로 사용할 수 없다.

때문에 배열의 프로토타입에서 forEach 등의 내장함수 메서드를 빌려오는 방법이 있다. 그것은 바로 call 과 apply 이다.

가장 흔하게 사용하는 것은 Array.from이 있다.

 

let nodes = document.querySelectorAll('div');
// call 사용
Array.prototype.forEach.call(nodes, (el) => {console.log(el)})
// Array from 사용
Array.from(nodes).forEach((item) => {console.log(item)})

 

*부모 컴포넌트 A와 자식 컴포넌트 B가 있을 때, A는 state로 {name: "주석"}을 가지고 있고, 자식인 B에게 name값을 넘겨주었다. A의 state가 {name: "이"}로 바뀌었을 때, 어떤 과정을 거쳐 바뀐 값을 화면에 보여주는지 라이프사이클 흐름으로 그려보시오.

 

 

기존 : A Component : Constructor ⇒ setState({name: “르탄이”}) ⇒ render ⇒ (부모 render 안에 있는

    자식 컴포넌트로 넘어감.)
        B Component : constructor ⇒ render ⇒ componentDidMount

        A Component : componentDidMount

 

fetch 시 : A Component : fetch 완료 (setState({name: “진도사우르스”}) ⇒ 업데이트 발생 ⇒ render)
             fetch 완료 (render 데이터 B Component로 props 전달)
             B Component : new props ⇒ render ⇒ componentDidUpdate (componentDidMount는 최초 렌더링 시 한 번만 실행되기 때문에)
             A Component : componentDidUpdate

 

 

* SPA 방식과 MPA 방식은 무엇인가?

 

SPA는 한 개의 Single Page 로 구성된 Application 이다. MPA는 여러 개의 Multiple Page로 구성된 Application 이다. MPA의 경우 새로운 페이지를 요청할 때마다 정적 리소스가 다운로드 되며, 매번 전체 페이지가 다시 리 렌더링 된다. 하지만 SPA는 웹 어플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운로드한다. 그 이후, 새로운 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 갱신한다. 따라서 SPA는 CSR (클라이언트 서버 렌더링) 방식으로 렌더링 된다고 하며, MPA를 SSR (서버 사이드 렌더링) 방식으로 렌더링한다고 한다. MPA 장점은 SEO 관점에서 유리하다. 당연히 완성된 형태의 HTML 파일을 서버에서 전달 받아 검색엔진에 크롤링 되기 쉽기 때문에 그렇다. 또한, 첫 로딩이 매우 짧다. 이미 서버에서 렌더링해 가져오기 때문이다. 하지만 MPA 역시 단점이 있다. 새로운 페이지를 이동하면 깜빡이며, 서버 렌더링에 따른 과부하가 있다. SPA의 경우 장점은 자연스러운 사용자 경험을 제공한다는 점과 필요한 리소스만 부분적으로 로딩이 가능하다는 점이다. 또한 서버의 탬플릿 연산을 클라이언트로 분산할 수 있으며, 컴포넌트별 개발에 용이하다. 하지만 SPA 단점 역시 존재하는데, 가장 큰 단점은 Javascript 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도가 느리다는 점이다. 또한 검색엔진최적화 SEO 가 어렵다.

 

 

* 단방향 바인딩과 양방향 바인딩은 무엇인가? 또한, 양방향 바인딩의 간략한 구조를 설명하라.

 

리액트는 기본적으로 단방향 데이터 바인딩을 사용한다. 즉, 부모 컴퍼넌트에서 자식 컴퍼넌트로 데이터를 넘겨주는 구조라는 것이다. 양방향 바인딩의 경우 데이터의 변경을 프레임워크 자체에서 감지하고 있다가 데이터가 변경되는 시점에 DOM 객체에 렌더링을 해주거나 페이지 내에서 모델의 변경을 감지해 JS 실행부에서 변경하는 양방향 데이터 바인딩이다. 양방향 데이터 바인딩의 장점은 코드량을 줄여준다는 점이 있지만 단점은 변화에 따라 DOM 객체 전체를 렌더링해주거나 데이터를 바꿔주기 때문에 성능이 감소되는 경우가 있다.

 

vue.js 문서를 보고 생각한 그림은 다음과 같다.

 

그림판으로 그려서 조금 서툽니다.

 

 

그럼 하나의 거대한 State를 사용하는 Redux의 구조와 유사한 것이 아닌가 생각이 든다.

 

 

* Redux란 무엇이며, 어떤 경우에 사용하고, 장점이 무엇인지 말해보시오.

 

Redux 란 어플리케이션의 클라이언트쪽 state를 관리하기 위한 거대한 이벤트 루프이다. 보통, 부모 컴퍼넌트에서 자식 컴퍼넌트에 props를 제공하거나, 자식 컴퍼넌트에서 new Props에 영향을 줄 때, 부모 컴퍼넌트에서 반응하기 어렵다. 또한 이런 단방향성의 바인딩 구조에서 Redux는 하나의 빛이다. Redux는 클라이언트 앱의 복잡성을 제어하기 위한 하나의 state 제어 수단이며, store라는 커다란 하나의 state를 만들어 각각의 컴퍼넌트에 제공하며, 이 state를 제어하기 위해선 오로지 순수 함수인 reducer가 사용된다. 특히 redux는 대형 프로젝트에서 state를 관리할 때 아주 유용하게 사용된다. redux를 사용하면 장점은 app의 state 변화가 예층 가능하게 변한다는 점이다. 특정 액션이벤트 발생에만 reducer가 작동되게 했기 때문에 어디서 state를 변하게 했는지 찾기 쉽다.

 

* 리액트에서는 DOM 요소에 접근하기 위해 주로 ref를 씁니다. domcument.getElementsByClassName 등을 쓰는 게 아니라 ref를 쓰는 이유는 무엇일까요?

 

 

우리가 실제 사용하고 있는 것은 실제 DOM 요소가 아니라 React 요소이다. 따라서 실제 DOM 에 접근하는 document.getElementByClassName 등을 사용하면 에러가 발생할 수 밖에 없다. 따라서 직접 접근하지 않고 가상 돔 자체에서 DOM 요소에 접근할 수 있는 ref를 사용한다.

 

부가설명 : input에 입력된 value 자체를 onChange시 setState로 지정시키면 계속 리렌더링된다. console에 찍어보면 가장 편하다. 하지만 useRef를 사용하게 되면 기억하고 있다가 호출할 때 만 렌더링 된다.