📗목차
왜 리액트인가?
자바스크립트만으로도 규모가 큰 애플리케이션을 만들 수 있는 시대가 왔다.
대규모 애플리케이션 중 프런트엔드 사이드에서 돌아가는 애플리케이션 구조를 관리하려면 어떻게 해야 할까?
특별한 도구 없이 순수하게 자바스크립트로만 관리하려면 골치가 아플 것이다.
지금까지 수많은 프레임워크가 조금씩 다른 관점에서 이를 해결하려고 노력해왔다.
Angular, Backbone.js, Derby.js, Ember.js, Ext.js, Knockback.js, Sammy.js PureMVC, Vue.js 등...
이 프레임워크들은 주로 MVC 아키텍처, MVVM 아키텍처를 사용한다.
MVC, MVVM, MVW 등과 같은 여러 구조가 지닌 공통점은 모델(Model)과 뷰(View)가 있는 것이다. 모델은 애플리케이션에서 사용하는 데이터를 관리하는 영역, 뷰는 사용자에게 보이는 영역이다. 컨트롤러는 프로그램이 사용자에게서 어떤 작업을 받으면 모델 데이터를 조회하거나 수정하고, 변경된 사항을 뷰에 반영한다.
반영하는 과정에서 보통 뷰를 변형하는데 예를 들어 JSON 객체 값을 사용하는 뷰가 있다고 하면,
{
"title": "리액트를 다루는 기술",
"contents": "리액트란?",
"author": "김민준",
"likes": 1000
}<div id="post-1">
<div class="title">리액트를 다루는 기술</div>
<div class="contents">리액트란?</div>
<div class="author">김민준</div>
<div class="likes">1000</div>
</div>like 값을 2000으로 업데이트한다면 애플리케이션에서 post-1의 likes 요소를 찾아 내부를 수정해야한다. 업데이트하는 항목에 따라 어떤 부분을 찾아서 변경할지 규칙을 정하는 작업은 간단하지만, 애플리케이션 규모가 크면 상당히 복잡해지며 성능도 떨어질 수 있다.
페이스북 개발 팀은 이를 해결하려고 하나의 아이디어를 고안한 것이 기존 뷰를 날려 버리고 처음부터 새로 렌더링하는 방식이다. 이렇게 하면 애플리케이션 구조가 매우 간단하고, 작성해야 할 코드양도 많이 줄어든다. 그저 뷰가 어떻게 생길지 선언하며 데이터에 변화가 있으면 기존에 있던 것은 버리고 정해진 규칙에 따라 새로 렌더링하면 되는 것이다.
페이스북 개발 팀은 최대한 성능을 아끼고 편안한 사용자 경험을 제공하면서 구현하고자 개발한 것이 리액트이다.
리액트란
리액트는 자바스크립트 라이브러리로 사용자 인터페이스를 만드는 데 사용하고, 구조가 MVC, MVW 등인 프레임워크와 달리, 오직 V(View)만 신경 쓰는 라이브러리다.
리액트는 특정 부분이 어떻게 생길지 정하는 선언체가 있는데, 이를 컴포넌트라고 한다.
컴포넌트는 재사용이 가능한 API로 수많은 기능들을 내장하고 있고, 컴포넌트 하나에서 해당 컴포넌트의 생김새와 작동 방식을 정의한다.
<컴포넌트의 기능>
-
가독성을 획기적으로 높일 수 있다.
-
재사용성이 높아진다.
-
만약 top.html이란 파일에서 버그가 있거나 개선을 해야되는 경우에도 top.html 의 변경된 내용이 이 파일을 사용하고 있는 모든 태그들에서 동시 다발적으로 업데이트가 일어난다.
→ 유지보수가 훨씬 더 편리해진다는 폭발적인 효과를 제공해줍니다.
사용자 화면에 뷰를 보여주는 것을 렌더링이라 한다.
리액트는 어떻게 데이터가 변할 때마다 새롭게 리렌더링하면서 성능을 아끼고, 최적의 사용자 경험을 제공할 수 있나?
이는 컴포넌트가 최초로 실행한 '초기 렌더링'과 컴포넌트의 데이터 변경으로 다시 실행되는 '리렌더링' 개념을 파악해야 한다.
초기 렌더링
render 함수는 컴포넌트가 어떻게 생겼는지 정의하는 역할을 한다.
이 함수는 html 형식의 문자열을 반환하지 않고, 뷰가 어떻게 생겼고 어떻게 작동하는지에 대한 정보를 지닌 객체를 반환한다.
컴포넌트 내부에는 또 다른 컴포넌트들이 들어갈 수 있다. 이 때 render 함수를 실행하면 그 내부에 있는 컴포넌트들도 재귀적으로 렌더링한다. 이렇게 최상위 컴포넌트의 렌더링 작업이 끝나면 지니고 있는 정보들을 사용하여 HTML 마크업을 만들고, 이를 우리가 정하는 실제 페이지의 DOM 요소 안에 주입한다.
렌더링 → HTML 마크업 → DOM
조화 과정 (리렌더링)
리액트의 업데이트 진행 과정을 한번 알아보자.
컴포넌트에서 데이터에 변화가 있을 때 우리가 보기에는 변화에 따라 뷰가 변형되는 것처럼 보이지만, 사실은 새로운 요소로 갈아끼우는 것이다.
이 작업 또한 render함수가 수행한다.
컴포넌트는 데이터를 업데이트 했을 때 단순히 업데이트한 값을 수정하는 것이 아니라, 새로운 데이터를 가지고 render 함수를 또 다시 호출한다. 그러면 그 데이터를 지닌 뷰를 생성하는데, 이 때 render 함수가 반환하는 결과를 곧바로 DOM에 반영하지 않고, 이전에 render 함수가 만들었던 컴포넌트 정보와 현재 render 함수가 만든 컴포넌트 정보를 비교한다.
자바스크립트를 사용하여 두가지 뷰를 최소한의 연산으로 비교한 후, 둘의 차이를 알아내 최소한의 연산으로 DOM 트리를 업데이트 하는 것이다.
결국 방식 자체는 루트 노드부터 시작해서 전체 컴포넌트를 처음부터 다시 렌더링하는 것처럼 보이지만, 사실 최적의 자원을 사용하여 수행하는 것이다.
리액트 특징
Virtual DOM
리액트의 주요 특징 중 하나는 Virtual DOM을 사용하는 것이다.
실제 DOM에 접근하지 않고 추상화한 자바스크립트 객체를 구성하여 사용한다. (마치 실제 DOM의 가벼운 사본과 비슷)
리액트에서 데이터가 변해 웹 브라우저에 실제 DOM을 업데이트할 때는 다음 세가지 절차를 밟는다.
-
데이터를 업데이트 하면 전체 UI를 Virtual DOM에 리렌더링한다.
-
이전 Virtual DOM에 있던 내용과 현재 내용을 비교한다.
-
바뀐 부분만 실제 DOM에 적용한다.
Virtual DOM의 오해
Virtual DOM을 사용한다고 해서 사용하지 않을 때와 비교하여 무조건 빠른 건 아니다.
리액트 메뉴얼에는 다음 문장이 있다.
우리는 다음 문제를 해결하려고 리액트를 만들었습니다.
지속적으로 데이터가 변화하는 대규모 애플리케이션 구축하기
작업이 매우 간단할 때는(단순 라우팅 정도만 있는 정적인 페이지) 리액트를 사용하지 않는 편이 더 나은 성능을 보이기도 한다.
리액트와 Virtual DOM이 언제나 제공할 수 있는 것은 바로 업데이트 처리 간결성이다. UI를 업데이트하는 과정에 생기는 복잡함을 모두 해소하고, 더욱 쉽게 업데이트에 접근할 수 있다.
기타 특징
리액트는 오직 뷰(View)만 담당한다.
다시 한번 강조하면 리액트는 프레임워크가 아니라 라이브러리다.
다른 웹 프레임워크가 Ajax, 데이터 모델링, 라우팅 등과 같은 기능을 내장하고 있는 반면, 리액트는 정말 뷰만 신경쓰는 라이브러리이므로 기타 기능은 직접 구현해야 된다.
하지만, 걱정할 거 없다. 다른 개발자들이 만든 라이브러리, 즉 라우팅에는 리액트 라우터, Ajax 처리에는 axios나 fetch, 상태 관리에는 리덕스(redux)나 MobX를 사용하여 빈 자리를 채워나가면 된다. 해당 분야에는 마음에 드는 라이브러리를 사용하면 되니까 자신의 취향대로 스택을 설정할 수 있는 장점이 있지만, 여러 라이브러리를 접해야 하는 단점도 있다.
또 리액트는 다른 웹 프레임워크나 라이브러리와 혼용할 수 있다. 예를 들어 Backbone.js, AngularJS 등의 프레임워크와 함께 언제든지 사용 가능하다.
참고문헌
김민준,「리액트를 다루는 기술 :실무에서 알아야 할 기술은 따로 있다!」, 길벗, 개정판[실은 2판] 2019 (개정판)
boostcourse, 웹 프론트엔드 시작하기(리액트&리덕스) , https://www.boostcourse.org/web231/lecture/1380895
