리액트 생명주기, 렌더링 방식 특징

[1] 리액트 생명주기 (Life Cycle)

Lifecycle = 생명주기

사람의 생명주기 : 출생 후 인생을 살다가 노화로 사망
리액트 컴포넌트도 이러한 생명주기를 가지고 있음
컴포넌트가 생성되는 시점과 사라지는 시점이 정해져있음

출생,인생,사망으로 나뉘어져 있음

각 과정의 초록색 표시부분은 생명 주기에 따라 호출되는 클래스 컴포넌트 함수
해당 함수를 Lifecycle Method라고 불리며,
번역하면 생명 주기 함수

먼저 컴포넌트가 생성되는 시점 (사람으로 말하면 출생)

이 과정을 "마운트"라고 부르는데 이때 컴포넌트의 constructor(즉 생성자)가 생성
생성자에서는 컴포넌트의 state를 정의
컴포넌트가 렌더링 되며, 이후에 ComponentDidmount 함수가 호출

태어난 모두는 각자 인생을 살아감
사람은 인생을 살아가는동안 신체적,정신적으로 변화를 겪음
이처럼 react 컴포넌트도 생애동안 변화를 겪으면서 여러 번 렌더링 
이를 react 컴포넌트로 말하면 update 되는 과정이라고 볼 수 있음.

update과정에서는 component의 props가 변경되거나 set state 함수 호출에 의해 state가 변경되거나 
forceUpdate 라는 강제 업데이트 함수 호출로 인해 컴포넌트가 다시 렌더링
그리고 렌더링 이후에 componentDidUpdate 함수가 호출

마지막으로 사망과정
사람은 누구나 나이를 먹고 죽게 됨
리액트 컴포넌트도 결국 언젠가는 사라지는 과정을 겪게 되는데
이 과정을 unmount

 

component가 unmount가 되는 시점  
상위 컴포넌트에서 현재 컴포넌트를 더이상 화면에 표시하지 않게 될때 unmount 된다고 볼수 있음
이때 unmount 직전에 componentWillUnmount 함수가 호출


여기서 배운 3가지 생명주기 함수이후에도 다른 생명주기가 존재
지금은 클래스 컴포넌트를 거의 사용하지 안하기 때문에 다루지 않음 중요 내용은
컴포넌트가 계속 존재하는 것이 아니라 시간의 흐름에 따라 생성되고 업데이트 되다가 사라진다는 것

=> 클래스 컴포넌트 뿐만 아니라 함수 컴포넌트에도 해당하는 내용

[2] 렌더링 방식에 따른 특징

SPA : Single Page Application : 하나의 페이지로 구성된 웹 어플리케이션 
MPA : Multi Page Application : 여러개의 페이지로 구성된 웹 페이지 구성방식
// CSR,SSR과 밀접한 관계가 있음

CSR(Client-Side-Rendering) : 클라이언트측에서 렌더링 하는 방식
SSR(Server Side Rendering) : 서버측에서 렌더링 하는 방식
 =>어느쪽에서 렌더링 준비하는지에 따라 나뉘는 개념

SSG(Static Site Generation)
서버에서 HTML을 보내준다는 측면에서 SSR과 비슷하지만 언제 만들어 주느냐에 차이가 있음

 

SPA는 웹 어플리케이션에 필요한 정적리소스를 초반 한번에 모두 다운로드하고
새로운 페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달받아 클라이언트에서 페이지를 갱신
=> 자연스럽게 렌더링 방식으로 CSR을 사용

MPA는 새로운 요청에 있을때마다 서버에서 이미 렌더링된 정적 리소스를 받음

=> 렌더링 방식으로 SSR을 사용

두 개념은 페이지 개수, 렌더링 위치에 따라 달라지는 개념

 

일반적으로

SPA는 렌더링 방식으로 CSR 
MPA는 렌더링 방식으로 SSR을 사용

최근 대부분 웹 어플리케이션이 SPA이니 가장 많이 사용되는 렌더링 방식도 CSR,

가장 좋은 렌더링 방식이기에 사람들이 가장 많이 사용하는 것?

SSR은 요청시 서버에서 즉시 HTML을 만들어서 응답 

=> 데이터가 달라지거나 자주 바뀌어서 미리 만들어 두기 어려운 페이지에 적합

SSG는 페이지들을 서버에 모두 만들어둔 뒤에 요청시에 해당 페이지를 응답하는 것

=> 바뀔 일이 거의 없어 캐싱 해두면 좋은 페이지에 사용하면 적합
캐싱 : 파일 복사본을 캐시 또는 임시 저장 위치에 저장하여 보다 빠르게 액세스할 수 있도록 하는 프로세스

CSR은  JS 파일을 다운로드 받아 동적으로 페이지를 만들어서 띄운다는 부분에 
CSR은 브라우저가 JS파일을 다운로드 받고 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에

초기 로딩 속도가 느림
하지만 초기 로딩 이후에 페이지 일부를 변경할때는 서버에 해당 데이터만 요청 => 이후 구동속도는 빠름

또, 서버가 빈 뼈대만 있는 HMTL을 넘겨주는 역할만 수행하면 되기 때문에 서버측에 부하가 적음
브라우저들이 가지는 웹 크롤러는 HTML을 읽어서 검색 가능한 색인을 만듦
웹 크롤러 봇 입장에서 본 HTML은 텅텅 비어져 있음 == 검색엔진이 색인을 할만한 콘텐츠가 존재하지 않음
이때문에 CSR은 검색엔진 최적화에 불리하다는 치명적인 단점이 있음


SSR은 유저가 웹사이트에 방문하면 브라우저에서 서버로 콘텐츠를 요청
먼저 서버에서 렌더링 준비를 마친 HTML을 브라우저의 응답으로 전달한다는 부분에 있어
모든 데이터가 이미 HTML에 담겨진채로 브라우저에 전달되기 때문에 검색엔진 최적화에 유리

JS를 실행 할줄 모르는 크롤러 봇도 무리없이 HTML을 읽을수 있음
또, 자바스크립트 코드를 다운로드 받고 실행하기 전에 사용자가 화면을 볼 수 있다는 점

JS다운로드를 기다려야했던 CSR보다 초기구동속도가 빠를 수 밖에 없음
하지만 동시에 이것이 치명적인 단점이 되기도 함
해당 시점에는 사용자가 버튼을 클릭하거나 이동하려고 해도 아무런 반응이 없을 수 있음
인터랙션 가능한 페이지처럼 보이지만, 그저 내용과 스타일이 입혀진 껍데기에 불과하고, 

실제로 클라이언트 측 JS가 실행되고 이벤트 핸들러가 첨부되어 

JS로직이 모두 연결될때까지 사용자의 입력에 응답할 수 없기 때문

사용자 입장에서는 아무런 반응이 없다면 난처함
이렇게 SSR에는 TTV(Time To View)와 TTI(Time To Interact) 간에 시간 간격이 존재한다는 것이 단점

반면에 CSR은 JS가 동적으로 DOM을 생성하기 때문에 
HTML은 JS로직이 모두 완전히 연결된 상태라 사용자가 보는 시점과 이용할 수 있는 시점이 동일

CSR,SSR 동작과정에 따른 장점과 단점

우선 CSR의 장점에는 화면 깜빡임이 없음. 
초기 로딩 이후 구동 속도가 빠름
TTV와 TTI사이 간극이 없음 => 전체적으로 매끄러운 사용자 경험이 특징 
서버에 부하가 클라이언트로 분산된다는 점
단점은 초기 로딩속도가 느리고, SEO(검색엔진 최적화)에 불리

SSR의 장점은 초기 구동속도가 빠르고 ,SEO에 유리
단점은 화면 깜빡임이 있고, 
TTV와 TTI사이 간극이 있어 사용자 경험이 나쁘며, 
매 페이지 로딩시마다 서버에 요청하므로 서버 부하가 있음


CSR도 단점이 있고 SSR도 단점이 있음.
그렇다면 어떤 방식을 사용하는 것이 좋을까?
서비스 성격에 따라 달라짐
만약 사용자와의 상호작용이 많고 대부분 페이지가 고객의 개인정보 데이터를 기준으로 구성되는 서비스
=> 검색포털 상위에 노출되는 것보다 오히려 고객의 데이터를 보호하는 것이 더 중요

모든 서비스 SEO가 필요하지는 않다는 의미 이런 서비스의 경우 SSR 보다 CSR이 더 적합
만약 회사 홈페이지이기 때문에 상위노출 되어야하고, 누구에게나 동일한 내용을 노출 하고 있고, 

만약 해당 페이지 데이터가 자주 바뀐다면 SSR이 더 적합 
내용을 업데이트 하는일이 거의 없다면 SSG가 적합
만약 사용자에 따라 페이지 내용도 달라지고, 빠른 인터랙션도 중요하고 검색엔진 최적화도 포기할 수 없다면
CSR + SSR 즉, 유니버셜 렌더링을 고려해보면 좋을 것