React : 사용 이유/장점

공통, 특화 프로젝트를 각각 React, React Native로 진행했다. 

처음에는 마냥 리액트가 업계에서 많이 쓰인다는 말을 듣고 사용하게 되었는데, 

그래서 정확히 무엇인지, 어떤 장점이 있는지 잘 모르고 있다는 생각에 포스팅을 해보기로 했다.

 

1. 리액트 상황
2. 리액트의 장점
    2.1 SSR과 SPA
    2.2 컴포넌트 기반의 화면 구성
    2.3 Virtual DOM
    2.4 선언형과 간결성
    2.5 리액티브 프로그래밍
    2.6 MVC 중 V만!
3. +번외
    3.1 SSR vs CSR / SPA vs MPA
    3.2

 

---

리액트 상황

2022년 자바스크립트 현황에 따르면 React가 4위로 나타난다. Solid, Svelte, Qwik 같은 새로운 프론트엔드 프레임 워크가 리액트에 도전 중이라고... 그래도 여전히 많은 기업에서 리액트를 사용하고 있다!

---

리액트의 장점 : SPA, CSR

리액트의 장점이라 하면 당연히 따라오는 것이 SPA(Single Page Application), CSR(Client Side Rendering)일 것이다. 

이전의 SSR은 변화가 있을 때마다 새롭게 전체 페이지를 다시 로드해야 했다. ajax로 바뀐 부분만 특정해 변화시킬 수 있지만 하나하나 동작을 지정하긴 쉽지않았다. 또, 서버에서 HTML, CSS, JS파일의 랜더링 방식은 안드로이드, IOS 등 다른 플랫폼과 서버를 공유할 수 없어 비효율 적이었다.

 

*ajax : <iframe>의 도입으로 페이지 내 부분적으로 문서 업데이트 가능 + XMLHttpRequest의 등장으로 JSON 형식으로 데이터 가져오기 가능 => JSON 데이터를 자바스크립트를 이용해 동적으로 HTML 반영하는 것. 

SPA의 시초가 된다.

 

CSR은 SSR과 달리 서버로부터 데이터를 받아 클라이언트에서 랜더링한다. 

이로써

1) 서버로부터 데이터를 받아 바뀐 부분의 데이터가 있는 화면만 새로 렌더링 => 사용자 경험을 높여주고 효율적으로 클라이언트 리소스 사용

2) HTML, CSS, JS 파일을 랜더링하는 대신 데이터를 보내줄 경우, 안드로이드, IOS, 웹 모바일 등 다양한 플랫폼이 서버 공유 가능 => 효율적 서버 운영

두가지 문제가 해결되었다! 

 

- CSR은 검색엔진 SEO 최적화를 할 수 없는 문제가 있는데, 리액트에서는 CSR과 SSR을 함께 사용할 수 있다. 이 장점은 다른 프론트엔드 프레임워크보다 더 사랑받았던 이유 중 하나이다! 

 

*더 자세한 SPA vs MPA / CSR vs SSR 내용은 번외에서 다루도록 하겠다!

 

---

리액트의 장점 : 컴포넌트 기반의 화면 구성

 

스스로 상태를 관리하는 캡슐화된 컴포넌트를 만드세요. 그리고 이를 조합해 복잡한 UI를 만들어보세요

 

 

리액트는 화면의 한 부분을 컴포넌트라는 단위로 나눌 수 있고 독립적으로 관리가 가능하다. 대규모 웹 애플리케이션에서 컴포넌트의 역할과 기능에 따라 따로 관리하기 용이하며 반복되는 부분을 대체해 코드 재사용성을 높인다. 또 컴포넌트 기반의 화면을 구성한다면 블록 쌓기처럼 컴포넌트를 쌓아 빠르고 효율적인 화면 구성을 할 수 있다.

---

리액트의 장점 : 가상 DOM

가상돔(Virtual DOM)?

UI의 이상적인 또는 "가상"적인 표현을 메모리에 저장하고 ReactDOM과 같은 라이브러리에 의해 "실제" DOM과 동기화하는 프로그래밍 개념. 이 과정을 재조정이라 한다.

기존에는 DOM(Document Object Model)을 조작해 브라우저 화면에 나타내는 형식이었다. 

DOM 자체의 성능이 느리진 않지만, 매번 DOM 전체를 직접 접근해 변화를 주면 HTML, CSS, JS 파일 전체를 다시 리랜더링하기 때문에 느려질 수 밖에 없다. 

 

이에 리액트는 가상 DOM을 사용해 실제 DOM 조작 횟수를 줄여 성능을 빠르게 개선했다. 

가상 DOM 사용 방식 : 데이터가 변경되면 리액트는 가상 DOM을 변경한다. 그리고 이전 가상 DOM과 비교해 변경된 부분을 체크하고 변경된 부분만 실제 DOM에 적용한다. 이러한 랜더링 방식은 DOM 전체를 매번 리랜더링했던 이전 방식에 비해 빠르고 애플리케이션 규모가 클수록, 데이터 변경이 많을수록 더 큰 힘을 발휘한다.

 

데이터 변경 -> 가상 DOM 리랜더링 -> 이전 가상 DOM과 비교 -> 변경된 부분 실제 DOM에 적용

가상 DOM의 또다른 장점은 쉽게 테스트할 수 있다는 것이다. 페이스북의 Jest를 사용하면 쉽게 테스트를 작성하고 컴포넌트 테스트가 가능하다.

 

---

리액트의 장점 : 선언형과 간결성

선언형
React는 상호작용이 많은 UI를 만들 때 생기는 어려움을 줄여줍니다. 애플리케이션의 각 상태에 대한 간단한 뷰만 설계하세요. 그럼 React는 데이터가 변경됨에 따라 적절한 컴포넌트만 효율적으로 갱신하고 렌더링합니다.
선언형 뷰는 코드를 예측 가능하고 디버그하기 쉽게 만들어줍니다.

 

let people = [{name: "r", age: 16},
{name: "e", age:12},
{name:"a", age:20},
{name: "c", age: 22},
{name: "t", age: 34}];

let adult = [];

for(let i = 0; i < people.length; i++) {
	if(people[i].age > 19) adult.push(people[i]);
}

console.log('adult :', adult); 

위 코드는 명령형으로 짜여진 코드이다.

let people = [{name: "r", age: 16},
{name: "e", age:12},
{name:"a", age:20},
{name: "c", age: 22},
{name: "t", age: 34}];

let adult = people.filter(people => people.age > 19);

console.log('adult :', adult); 

위 코드는 filter 함수를 사용해서 선언형으로 다시 작성한 코드

 

---

리액트의 장점 : 리액티브 프로그래밍

리액트라는 이름에 걸맞게 리액트는 반응형 프로그래밍이다. 

이는 말 그대로 '바로 응답하는 프로그래밍'을 뜻한다. 엄격하게 따지면 리액트는 리액티브 프로그래밍 패러다임에 완벽히 부합하진 않지만 '사용자의 요청에 바로 응답하는' 이 핵심 개념에 부합한다.

 

리액트의 props를 이용한 상태(데이터)의 변화 전파와 전이는 사용자의 지속적인 요청에 바로 응답할 수 있게 한다.

또, 리액티브 프로그래밍의 특징 중 하나인 '유연성'도 가지고 있다.

데이터의 변화에 따라 지속적으로 랜더링될 때 일부 데이터가 없거나 비정상적인 데이터를 에러로 처리하지 않고 유연하게 처리한다. 리액트는 옵져버블, 스트림 같은 복잡한 개념 없이 상태를 자식 컴포넌트에 내려주고 상태를 변경에 따라 랜더링함으로서 자연스럽게 '바로 응답하는 프로그래밍'을 구현한다.

---

리액트의 장점 : 오직 View만!

사용자 인터페이스를 만들기 위한 JavaScript 라이브러리

다른 프론트엔드 프레임워크와 달리 리액트는 MVC 프레임워크가 아니다. Model, View, Controller 중 View만 제공한다.

그래서 프레임워크보단 라이브러리에 가깝다고 하는 것이다!

다른 부분은 리액트에서 제공하지 않기 때문에 다른 라이브러리를 사용해야함은 단점일 수 있지만,

반대로 원하는 라이브러리를 사용해 더 많은 문제를 해결할 수 있다. 리액트는 상태 관리 라이브러리로 Redux를 많이 사용하는데 Redux는 MVC 프레임워크의 양방향 상태 전이 문제점을 피할 수 있다.

리액트는 Controller, Model를 사용하는 대신 Flux 구조에 따라 Action -> Dispatcher -> Store의 단방향 데이터 흐름을 사용해 MVC 패턴의 양방향 상태 전이의 문제점을 해결할 수 있다. 다른 프레임워크의 경우 MVC 패턴을 강제하기 때문에 리액트처럼 다른 라이브러리를 사용해 쉽게 문제를 해결하기 힘들다. 

 

정리 : 리액트를 사용하면서 생각해 볼 것❓

1. SPA에서 데이터 변화가 있는 부분만 빠르게 랜더링 되고 있는지
2. 가상 DOM이 아니라 DOM를 직접 제어하는 부분이 많은지
3. 데이터 변화와 라이프 사이클을 잘 이해해서 랜더링을 최적화하고 있지
4. JSX에서 선언형 프로그래밍을 잘하고 있는지
5. UI는 사용자의 상호작용에 바로 반응하고 있는지
6. 리액트에 같이 구성된 다른 라이브러리를 잘 조합하고 있는지
   
   

---

[번외] CSR vs SSR / SPA vs MPA

기존의 Static Site

=> 문제점 : 페이지에서 다른 링크 클릭 시 다시 서버에서 그 페이지 HTML을 받아와 전체를 업데이트한다.

그 때마다 새로고침.

 

 

SSR : 서버 쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식

(서버에서 렌더링 후 전달)

(Static Site에서 받은 영감)

1) 유저가 웹 사이트 요청을 보낸다.

2) 서버는 즉시 렌더링 가능한 html 파일을 만든다.

3) 클라이언트에 전달되는 순간 HTML은 즉시 렌더링 된다. 하지만 사이트 자체는 조작 불가능

4) 클라이언트가 자바스크립트를 다운받는다

5) 다운받아지는 사이 유저는 컨텐츠를 볼 순 있지만 조작할 순 없다

6) 브라우저가 JavaScript 프레임워크를 실행

7) JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호 작용 가능.

 

=> 문제점 : Static Site의 화면 끊김, 깜빡임 여전히 존재. 웹사이트 전체를 서버로 가져오는 것이기 때문에 사용성 떨어짐

서버에 무리가 감. 사용자가 많을 수록 ..

html을 빠르게 볼 수 있지만 js 파일은 아직 다운로드 받지 못해 반응이 없는 경우가 발생함. 

 

CSR : 자바스크립트 파일을 브라우저에서 해석해 렌더링하는 방식 

(서버에서 HTML, JS를 전달하면 클라이언트에서 렌더링)

1) User가 Website 요청을 보냄

2) CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보냄

3) 클라이언트는 HTML과 JS 다운

4) 생략

5) 다운이 완료된 JS 실행, 데이터를 위한 API 호출 (이 때 유저들은 placeholder를 보게됨)

6) 서버가 API로부터 요청에 응답

7) API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는 상호작용 가능

<body>
	<div id="root"></div>
    <script src="app.js"></script>
</body>

=> 사용자가 첫 화면을 보기까지의 시간이 오래 걸림. SEO 성능이 좋지 않음. 

SEO (Search Engine Optimization) : 사이트가 검색 엔진으로 찾아지기에 적합하게 만드는 것. 

> 구글, 네이버 같은 검색엔진들은 서버에 등록된 사이트를 돌아다니며 HTML 안에 포함된 링크와 타이틀, 태그들을 보고 사용자가 빠르게 검색할 수 있도록 함. 하지만 CSR의 HTML body는 검색 엔진이 html을 분석하기 어렵다.

=> Static site에서 영감을 받은 SSR이 도입  

 

SPA	MPA
한 개의 Page로 구성된 Application	여러 개의 Page로 구성된 Application
웹 어플리케이션에 필요한 모든 정적 리소스를 최초 한번에 다운로드 페이지 갱신에 필요한 데이터만 전달받아 갱신	새로운 페이지를 요청할 때 마다 정적 리소스 다운, 매번 전체 페이지 다시 렌더링
CSR 방식으로 렌더링	SSR 방식으로 렌더링
SEO가 어려움 (SSR로 해결?) 초기 구동 속도의 느림 보안 이슈	SEO관점에서 유리, 첫 로딩이 매우 짧음
자연스러운 사용자 경험, 필요한 리소스만 부분적 로딩(성능) 서버 템플릿 연산을 클라이언트로 분산 ( 성능) 컴포넌트 별 개발 용이 ( 생산성 ) 모바일 앱 개발을 염두에 둔다면 동일한 API로 설계 가능( 생산성 )	새로운 페이지 이동 시 깜빡임

 

 

=> SEO 문제가 있는 SPA, 반짝임 문제가 있는 SSR... SPA에서 SSR을 할 수 없나?

Next.js.와 Nuxt.js (React, Vue) 사이트의 원하는 부분을 SSR로 만들어준다! 

이를 위해 API 서버와 별개로 Next.js, Nuxt.js 서버가 추가로 돌고 있어야 하는데, 이를 위해 Node.js가 깔린 서버에서 프로젝트를 어플리케이션으로 실행해 프론트 엔드를 배포한다.

이러한 방식으로 페이지의 요소들 중 페이지 접속 시 바로 나타나야 할 것들을 정해 서버에서 미리 렌더링해서 보내줄 수 있게 된다.

React : Next.js, Gatsby

Vue : Nuxt.js

 

 

SSG (Static Site Generator)

사전 렌더링을 저적 페이지로 생성해주는 방식. SSR처럼 서버로부터 완성된 HTML을 받아오지만 다른 점은 HTML 파일의 생성 시점이 빌드 타임이라는 것. ( SSR은 사용자 요청 시 생성 ) , Gatsby, Jekylle, Hugo.

 

[번외] 프레임워크 VS 라이브러리

프레임 워크 ?  모델 하우스를 짓는 것. 사용자는 모델하우스가 제공하는 청사진 안에서"만" 움직일 수 있음. 

통제권은 사용자가 아닌 프레임워크가 쥐고 있다. 

 

라이브러리 ? 이케아에서 산 재료로 가구를 조립하는 것 ! 재료의 선택이나 통제권은 사용자에게 있다. 

 

=> 제어의 역전화!??

개발자가 해왔던 일(제어)을 프로그램, 즉 프레임워크가 대신 해준다는 것.

프레임 워크는 제어권이 역전되었다! 제어 역전!

 

리액트(React)는 왜 쓰는 건데⁉

 

[Jest : 리액트의 테스트 라이브러리]

Jest로 기본적인 테스트 작성하기

[SSR vs CSR]

SSR과 CSR 비교하기

 

SPA vs MPA와 SSR vs CSR 장단점 뜻정리 - 하나몬

 

서버 사이드 렌더링(SSR)