🤔 리액트를 사용한다. 그런데 왜?

🤢 레이아웃

간단하게 현재 페이지를 기준으로 레이아웃을 나눠본다면 header, main, footer로 나눠볼 수 있을 것이다.

기존 jsp와 같은 Template을 통해서 페이지를 다룬다면 한 페이지의 코드는 아래의 이미지와 같을 것이다. 물론 아래의 페이지에는 DOM 제어를 위한 자바스크립트 코드는 포함되지 않았다.

만약 jsp페이지에서 여러 비동기 기능들을 다룬다고 할때 필요한 자바스크립트 코드의 길이는 자연스레 길어질 수 밖에 없다.

🤔 그렇다면 각 구역마다 파일을 나누고, Element마다 파일을 나눈다면?

각각의 나눈 부분들을 Component라고 한다면, 각 컴포넌트들은 쪼개진 부분에 대해서 각각 자신의 역할에 대해서만 신경쓰면 된다.
- 이는 어떻게 보면 객체 지향의 개념 중 '단일 책임 원칙(Single responsibility principle)'으로 각 컴포넌트들은 하나의 역할만, 기능만 사용하면 된다.

각 부위별로 나눔으로 인해

• 디버깅하기가 훨씬 용이하며
• 나눈 컴포넌트들은 각각 재사용이 가능하고
• 테스트 코드 작성이 용이하게 된다. (테스트 코드를 짤때는, 1기능 1테스트 코드)

사실 TDD를 몇년전부터 들어왔음에도 안써봐서, 테스트 코드를 잘 작성하고 싶은 욕망이 크다.

🤔 기존의 SSR(Server Side Rendering) 방식과 큰 특징이 뭔데?

렌더링 방식의 차이

기존의 SSR 방식은 jsp, php, asp.net과 같은 이미 만들어진 view page를 사용자에게 보여준다.
즉, Client browser에서 view page를 보여주는 것이 아닌, Server에서 사용자가 요청한'url'에 맵핑된 비즈니스 로직을 수행한 후, 사용자에게 보여줄 view(jsp)를 컴파일한 후 만들어진 html page를 사용자에게 응답하는 것이다.

반면 CSR(Client Side Rendering) 방식은 기존의 방식과 다르게 만들어진 html페이지를 broswer에게 보내지 않고, 사용자에게 뼈대(레이아웃) html을 응답하는데 이 때 사용자의 요청에 각 다른 응답을 보여주기 위한 'javascript file'을 같이 보내준다.

이로 인해 사용자가 브라우저를 조작해 특정 이벤트를 일으키면, 자바스크립트 파일은 각 이벤트에 맞는 dom을 기존 dom에서 변경하거나 삽입하여 사용자에게 보여준다. (이 때 virtual dom이라는 개념이 도입된다.)

이 모습이 마치 app을 조작하는 거와 비슷하여 CSR을 WebApp이라고도 부른다.

🤔 단점은 없어?

있지 있어

단점은 다양하다, SEO(Search Engine Optimization, 검색 엔진 최적화) SSR에 비해 비교적 느린 브라우저 초기 렌더링 속도, 기존방식에 비해 어려운 러닝커브, 상태 관리의 괴랄함 등

하지만, 필요에 따라 여러 라이브러리가 나오고 있고, 발전되어 가고 있다.

🤔 그래서 리액트는 왜 쓰는데?

써보고 싶어서