React
FE개발을 위한 자바스크립트 오픈소스 라이브러리
3가지 특징
선언형(Declarative)
html/css/js로 나눠서 적기보다는 하나의 파일에 명시적으로 작성할 수 있게 JSX를 활용한 선언형 프로그래밍을 지향함
컴포넌트 기반 (Component-based)
하나의 기능 구현을 위해 여러 종류의 코드를 묶어둔 컴포넌트를 기반으로 개발함. 컴포넌트로 분리하면 서로 독립적이고 재사용이 가능하기 때문에 기능 자체에 집중하여 개발 가능
장점:
독립성 => 기능 작동에 집중하여 개발 가능
재사용성 => 유지보수, 유닛테스트 편리
범용성 (Learn once, Write anywhere)
자바스크립트 프로젝트 어디에든 유연하게 적용 가능. Facebook에서 관리되어 안정적이고 가장 유명하며 리액트 네이티브로 모바일 개발도 가능
렌더링 방식
출처: React Docs: Render and Commit
요청 프로세스와 UI를 뿌려주는 방식은 크게 3가지 프로세스로 동작한다.
1. 렌더링 유발(triggering a render)
2. 컴포넌트 렌더링(rendering the component)
3. DOM에 올리기 (committing to the DOM)
step 1: 렌더링 유발
컴포넌트 렌더링이 일어나는 이유는 2가지 이다
- 컴포넌트의 첫 렌더링(초기 렌더링)인 경우
- 컴포넌트 내 state가 업데이트 된 경우
step 2: 컴포넌트 렌더링
렌더링: 리액트가 컴포넌트를 부르는 것
step 1단계 이후 리액트는 컴포넌트를 불러 무엇을 화면에 보여줄 지 파악한다.
- 초기 렌더링의 경우, 리액트는 root 컴포넌트를 부른다.
- 업데이트에 의한 렌더링일 경우, 리액트는 state가 업데이트 된 함수 컴포넌트를 부른다. 업데이트 된 컴포넌트들이 서로 중첩(nested)되어있을 경우 해당 컴포넌트들에 대한 렌더링이 재귀적으로 일어난다.
step 3: DOM에 화면 보여주기
컴포넌트 렌더링 이후 리액트는 DOM을 업데이트한다.
- 초기 렌더링의 경우, 리액트는
appendChild()DOM API를 이용해 화면에 뿌려준다. - 업데이트에 의한 렌더링일 경우, 최소한으로 필요한 작업을 계산하여 최신 state로 업데이트한다. DOM 노드를 살펴보고 업데이트 된 부분만 렌더링한다.
브라우저 페인트
리액트는 렌더링을 마친 후 브라우저를 리페인트 한다. 이를 'painting'이라고 한다.
Virtual DOM
리액트의 특징 중 하나로, 실제 DOM의 사본 같은 개념. 리액트는 실제 DOM 객체에 접근하는 대신 Virtual DOM에 접근하여 업데이트된 부분을 비교한 후 적용한다.
- Real DOM의 버추얼 표현방식
- 리액트는 Virtual DOM의 state 업데이트를 먼저한 후 Real DOM과 동기화한다
- Virtual DOM은 기계의 도면도/설명서/시뮬레이션 같은 것이다. 수정은 할 수 있지만 기계에 직접적으로 업데이트 내용이 반영되지는 않는다.
Virtual DOM 작동방식
가상 DOM은 가상의 UI 요소를 메모리에 유지시키고 이를 ReactDOM과 같은 라이브러리를 통해 실제 DOM과 동기화시키는 것. 매 렌더링마다 새로운 Virtual DOM이 만들어짐
=> Virtual DOM에서 실제 DOM에 필요한 부분만 반영할 수 있고, Real DOM처럼 브라우저에 실제로 그리는 것이 아니기 때문에 속도가 훨씬 빠름.
- 첫 로딩 시
ReactDOM.render()이 실행되면서 Virtual DOM 트리와 real DOM 트리가 만들어짐 - 어떤 이벤트(key press, left click, api resepnse..)가 발생했을 때, Vitual DOM 트리노드들은 props가 업데이트 되었음을 인식한다. 업데이트가 있는 노드는 업데이트가 진행되고 변화가 없는 노드들은 그 상태로 놔둔다.
- 이전 가상 DOM과 이후 가상 DOM의 차이를 비교 (Reconciliation - 재조정)
- 가상 DOM은 실제 DOM에 변경을 적용할 수 있는 최상의 방법을 계산
- 최적의 방법으로 렌더링 수행 가능
- 더 빠른 렌더링 가능
Real DOM vs Virtual DOM
| Real DOM | Virtual DOM |
|---|---|
| DOM manipulation is very expensive | DOM manipulation is very easy |
| There is too much memory wastage | No memory wastage |
| It updates Slow | It updates fast |
| It can directly update HTML | It can’t update HTML directly |
| Creates a new DOM if the element updates. | Update the JSX if the element update |
| It allows us to directly target any specific node (HTML element) | It can produce about 200,000 Virtual DOM - Nodes per Second. |
| It represents the Ul of your application | It is only a virtual representation of the DOM |
리액트는 Client-Side Rendering
리액트는 기본적으로 CSR 기반이다.
- CSR: 화면에 그려주기 위해 필요한 HTML을 웹브라우저가 Javascript를 실행하여 동적으로 만들어 주는 것. 해당 페이지 접속 후 HTML이 비어있음
- SSR: 웹브라우저가 서버로부터 받은 HTML을 화면에 뿌려주는 것. 해당 페이지 접속 후 HTML이 채워져 있는 것 볼 수 있음
1. 초기 로딩 속도
CSR은 비어있는 HTML을 다운받은 이후에 JS 파일을 다운받는다. 반면 SSR 방식의 경우 화면에 바로 그릴 수 있는 HTML이 준비되어 있기 때문에 브라우저가 바로 렌더링을 할 수 있다.
초기 로딩 속도는 SSR 방식이 더 유리하다.
2. SEO
SEO(Search Engine Optimization) - 검색엔진최적화 : 검색 엔진에 우리가 만든 페이지가 노출되는 것을 의미. HTML을 가지고 파악함.
CSR은 페이지 로딩 시 빈 HTML이므로 검색엔진봇이 데이터를 수집하기가 어려움. SSR은 각 페이지마다 HTML을 생성하므로 SEO에 유리함.
3. 서버 부담
CSR은 최초 Javascript 파일을 받아 렌더링을 하면 그 이후에 다시 다운로드해서 렌더링할 일이 없다. 페이지가 변경되더라도 이미 최초 Javascript에 필요한 페이지가 다 있으므로 추가로 서버에 요청할 일이 없다.
반면 SSR은 화면이 바뀔 때마다 HTML을 서버로부터 매번 받아와야한다.
서버 부담 측면에서는 CSR 방식이 더 유리하다.
리액트는 Single Page Application(SPA)
규모가 커질수록 사용자와의 상호작용이 많아지고 속도 저하 문제가 발생함에 따라 이 문제를 해결하기 위해 등장한 SPA
SPA 등장배경과 개념 (Single Page Application)
전통적인 웹사이트는 페이지 전체를 로딩하여 시간이 오래걸리는 반면, SPA는 페이지 전환 전후에 중복되는 부분은 새로 불러오지 않음 (ex. header, navigation, footer)
서버로부터 완전히 새로운 페이지를 불러오지 않고 화면 업데이트를 위해 필요한 데이터만 전달받아 브라우저에서 해당하는 부분만 업데이트 하는 방식
장점
- 필요한 데이터만 받아서 업데이트하기 때문에 사용자와의 interaction이 빠름
- 서버에서 요청받은 데이터만 넘겨주므로 서버 과부하문제가 현저하게 줄어듦
- 더 나은 유저경험 제공 (전체페이지 렌더링하지 않아도 되기 때문)
- 대표적인 플랫폼: 유튜브, 페이스북, 지메일, 에어비엔비, 넷플릭스 등
단점
- SPA의 JavaScript 파일의 크기가 크기때문에 첫 화면 로딩시간이 길어짐 (HTML파일은 거의 비어있고 JavaScript파일에 대부분의 코드가 들어있음)
- 검색엔진 최적화가 좋지 않음: 검색엔진(구글, 네이버)은 HTML 파일에 있는 자료를 분석하여 검색기능을 구동하지만 SPA의 경우 HTML에는 별다른 자료가 없기 때문 => 검색엔진 최적화를 할 수 있도록 발전하는 중 🚀
