velopert님의 <리액트를 다루는="" 기술=""> 개정판과 inflearn의 [따라하며 배우는 노드, 리액트 기본](https://www.inflearn.com/course/%EB%94%B0%EB%9D%BC%ED%95%98%EB%A9%B0-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%85%B8%EB%93%9C-%EB%A6%AC%EC%95%A1%ED%8A%B8-%EA%B8%B0%EB%B3%B8)를 보고 공부한 것을 정리합니다.

react JS

Library, Made by Facebook, Released in 2013

현재 자바스크립트는 웹 애플리케이션에서 가장 핵심적인 역할 더 나아가 영역을 확장하여 서버 사이드는 물론 모바일, 데스크톱 애플리케이션에서도 활약 이제 자바스크립트만으로도 규모가 큰 애플리케이션을 만들 수 있는 시대! -> 그렇다면, 대규모 애플리케이션 중 프론트엔드 사이드에서 돌아가는 애플리케이션 구조를 관리하려면 어떻게 해야 할까? 라는 문제

기존에 많이 사용되는 MVC 아키텍처 (Model, View, Controller)

• 모델은 애플리케이션에서 사용하는 데이터를 관리
• 뷰는 사용자에게 보이는 부분
• 프로그램이 사용자에게서 어떤 작업(예: 버튼 클릭, 텍스트 입력 등)을 받으면 컨트롤러는 모델 데이터를 조회하거나 수정하고, 변경된 사항을 뷰에 반영
• 반영하는 과정에서 보통 뷰를 변형(mutate)

업데이트하는 항목에 따라 어떤 부분을 찾아서 변경할지에 대한 규칙을 정하는 작업은 간단하지만, 애플리케이션 규모가 크면 상당히 복잡해지고 제대로 관리하지 않으면 성능도 떨어질 수 있다.

그렇다면, 어떤 데이터가 변할 때마다 어떤 변화를 줄지 고민하는 것이 아니라 그냥 기본 뷰를 날려 버리고 처음부터 새로 렌더링하면 어떨까? (by Facebook)

리액트는 사용자 인터페이스를 만드는 데 사용하는 라이브러리이다. MVC 중에서도 오직 V(view)만 신경쓰는 라이브러리이다.

다른 웹 프레임워크가 Ajax, 데이터 모델링, 라우팅 등과 같은 기능을 내장하고 있는 반면, 리액트는 정말 뷰만 신경쓰는 라이브러리이므로 기타 기능은 직접 구현하여 사용해야 한다.

라우팅에는 리액트 라우터, Ajax 처리에는 axios나 fetch, 상태 관리에는 리덕스(redux)나 MobX를 사용할 수 있다. 해당 분야에서 마음에 드는 라이브러리를 사용하면 되기 때문에 자신의 취향대로 스택을 설정할 수 있다는 장점이 있지만, 여러 라이브러리를 접해야 한다는 단점도 있다.

또 리액트는 Backbone.js, Angular JS 등의 프레임워크나 라이브러리와 혼용할 수도 있다.

component

리액트 프로젝트에서 특정 부분이 어떻게 생길지 정하는 선언체가 있는데, 이를 컴포넌트(component)라고 한다. 템플릿과는 다른 개념! 컴포넌트는 재사용이 가능한 API로 수많은 기능들을 내장하고 있으며, 컴포넌트 하나에서 해당 컴포넌트의 생김새와 작동 방식을 정의한다.

렌더링 : 사용자 화면에 뷰를 보여주는 것

리액트 컴포넌트는 최초로 ‘초기 렌더링’을 실행하고, 데이터 변경이 일어나면 다시 ‘리렌더링’이 실행된다.

초기 렌더링

어떤 UI 관련 프레임워크, 라이브러리를 사용하든지 맨 처음 어떻게 보일지를 정하는 초기 렌더링이 필요하다. 리액트에서는 render()가 이를 담당한다. render() {...}

이 함수는 뷰가 어떻게 생겼고 어떻게 작동하는지에 대한 정보를 지닌 객체를 반환한다. 컴포넌트 내부에는 또 다른 컴포넌트들이 들어갈 수 있는데, render 함수를 실행하면 그 내부에 있는 컴포넌트들도 재귀적으로 렌더링한다.

이렇게 최상위 컴포넌트의 렌더링 작업이 끝나면 지니고 있는 정보들을 사용하여 HTML 마크업을 만들고, 이를 우리가 정하는 실제 페이지의 DOM 요소 안에 주입한다.

조화 과정

리액트에서 뷰를 업데이트할 때는 “업데이트 과정을 거친다”라고 하기보다는 “조화 과정(reconcilation)을 거친다”라고 하는 것이 더 정확한 표현이다. 업데이트 과정에서 뷰가 변형되는 것이 아니라, 내부적으로는 새로운 요소로 갈아끼우는 것이기 때문이다.

이 작업 역시 render 함수가 하는 일이다. 컴포넌트는 데이터를 업데이트했을 때 단순히 업데이트한 값을 수정하는 것이 아니라, 새로운 데이터를 가지고 render 함수를 또 다시 호출한다.

이때 이전에 render 함수가 만들었던 컴포넌트 정보(스냅샷)와 현재 render 함수가 만든 컴포넌트 정보를 비교한다. 자바스크립트를 사용하여 두 가지 뷰를 최소한의 연산으로 비교한 후, 둘의 차이를 알아내 최소한의 연산으로 DOM 트리를 업데이트한다. (diffing 과정)

real DOM에 바로 변화를 업데이트하게 되면 전체를 reload하는 과정이 수반되기 때문에 시간이 오래 걸리지만, 이렇게 두 가지 뷰를 비교하여 변경이 발생한 부분만을 갈아 끼우게 되면 자원이 절약되면서 훨씬 더 빠르게 변화가 일어난다.

virtual DOM

DOM

Document Object Model 객체로 문서 구조를 표현하는 방법으로, XML이나 HTML로 작성한다. 웹 브라우저는 DOM을 활용하여 객체에 자바스크립트와 CSS를 적용한다. DOM은 트리 형태이기 때문에 특정 노드를 찾거나(탐색), 수정하거나(업데이트), 제거하거나(삭제), 원하는 곳에 삽입할 수 있다.

DOM은 과연 느릴까? DOM은 동적 UI에 최적화되어 있지 않다는 치명적인 약점이 있다.

DOM 자체는 빠르다. DOM 자체를 읽고 쓸 때의 성능은 자바스크립트 객체를 처리할 때의 성능과 비교하여 큰 차이가 나지 않는다. 단, 웹 브라우저 단에서 DOM에 변화가 일어나면 웹 브라우저가 CSS를 다시 연산하고, 레이아웃을 구성하고, 페이지를 리페인트한다. 이 과정에서 시간 자원이 소모된다.

해결법 DOM을 최소한으로 조작한다! 리액트는 Virtual DOM 방식을 사용하여 DOM 업데이트를 추상화함으로써 DOM 처리 횟수를 최소화하고 효율적으로 진행한다.

Virtual DOM

Virtual DOM을 사용하면 실제 DOM에 접근하여 조작하는 대신, 이를 추상화한 자바스크립트 객체를 구성하여 사용한다. 마치 실제 DOM의 가벼운 사본 과 비슷하다.

리액트에서 데이터가 변하여 웹 브라우저에 실제 DOM을 업데이트할 때 밟게 되는 절차는 다음과 같다.

1. 데이터를 업데이트하면 전체 UI를 Virtual DOM에 리렌더링한다.
2. 이전 Virtual DOM에 있던 내용과 현재 내용을 비교한다.
3. 바뀐 부분만 실제 DOM에 적용한다.

그렇다면 Virtual DOM을 사용하면 어떤 상황에서나 무조건 빠를까? 다음은 리액트 매뉴얼에 있는 문장이다.

우리는 다음 문제를 해결하려고 리액트를 만들었습니다. 지속적으로 데이터가 변화하는 대규모 애플리케이션 구축하기

단순 라우팅 정도만 있는 정적인 페이지에서는 오히려 리액트를 사용하지 않는 편이 더 나은 성능을 보이기도 한다. 리액트와 Virtual DOM이 언제나 제공할 수 있는 것은 바로 업데이트 처리 간결성 이다. UI를 업데이트하는 과정에서 생기는 복잡함을 모두 해소하고, 더욱 쉽게 업데이트에 접근할 수 있다.