리액트를 사용하는 이유에 대한 생각 정리

*해당 포스팅의 내용은 문서에 기반한 fact가 아닌, 개인의 생각 정리를 위한 글이므로 이 글을 읽으시는 분들은 이 점 유의해주세요.

다룰 내용 정리:

 

리액트를 사용하는 이유

1. VS 바닐라 JS

2. VS 다른 프레임워크

 

 

1. VS 바닐라 JS

바닐라 JS에서 화면을 수정하려면 1. 관련 데이터 수정하기, 2. 관련 DOM 수정하기 를 해줘야 합니다.

반면 리액트는 화면을 수정하려면 화면과 관련된 데이터(state)만 갱신해주면 됩니다. (화면 갱신은 React가 알아서 해줌)

 

바닐라 JS의 경우 DOM을 수정하는 작업까지도 절차적으로 직접 해줘야 하는 영역이었는데

반면 리액트에서는 View와 연관된 데이터만 바꾸면 그 데이터가 끼어있는 영역의 View가 알아서 알아서 바뀐다는 점에서 선언적인 느낌으로 View 단 코드를 짤 수 있게 된다는 점에서 개발자의 생산성이 올라간다고 볼 수 있습니다.

 

다시 정리하면,

바닐라 JS는 데이터도 수정하고 바뀐 데이터에 대응하도록 화면도 '직접' 수정한다면(이러면 화면이 복잡해지고 유저의 인터렉션이 많은 화면에서 코드를 짜기가 매우 어려워지겠죠?)

리액트는 데이터만 수정하면 알아서 화면이 갱신된다.(즉, 개발자 입장에선 화면 갱신을 일으키는 데이터만 다뤄주면 되므로 편해집니다)

 

---

 

리액트에서 이게 가능한 이유:

 

위에서 언급한 데이터는 state이며 이 state는 setState로 갱신이 됩니다. setState가 컴포넌트에게 re-rendering 하라고 '요청'하면 리액트는 re-rendering이 되어야 하는 컴포넌트들을 다시 화면에 그립니다.

 

이때 virtual DOM이 등장합니다. virtual DOM은 실제 DOM tree를 본떠 만든 메모리에 저장된 가상의 DOM입니다.(javascript object tree) 이 virtual DOM은 setState가 될 때 수정이 되는데요, 수정이 된 후 실제 DOM tree와 비교 후 수정된 DOM Node만 다시 그려지는 것이죠.

 

다시 정리하면,

개발자는 setState만 잘해줘도 리액트가 알아서 DOM을 갱신해준다. 이때 리액트는 virtual DOM을 활용한다.

 

---

 

setState의 동작 원리?

 

setState는 비동기 방식으로 동작합니다. setState가 호출될 때마다 동기적으로 화면 갱신이 이뤄지면 너무 많은 화면 갱신이 이뤄질 것이기 때문입니다. 그래서 batch 방식으로 setState를 모아 한 번에 화면을 갱신하는 것입니다. 이 부분과 관련해서는 더욱 deep 한 공부가 필요할 거 같습니다.

 

---

 

위에서 리액트는 선언적인 코드를 짤 수 있다고 했는데...

 

리액트 덕분에 UI를 그릴 때 코드를 더욱 선언적으로 작성할 수 있게 되긴 했지만 모든 부분에서 그럴 순 없을 것입니다.

상태를 어떻게 관리할 것인지에 대한 로직부터 event handler, data fetch, local storage, subscribe 등등 많은 요소가 절차적인 프로그래밍을 해야 하는 부분이죠.

 

그런데 적어도 위의 절차적인 로직이 필요한 부분들을 리액트 컴포넌트(UI가 그려지는 작은 단위가 컴포넌트)에서 분리할 수 있는 방법이 생겼습니다.

 

Functional Component 방식이죠.

 

---

 

Class Component vs Functional Component

 

기존 클래스형 컴포넌트는 내부의 state를 다루기 위해 관련 로직들도 같이 적어주어야 했습니다. 그리고 이 로직들은 UI 관련 코드가 적혀있는 컴포넌트와 결합되는 상태가 되어버리죠. 

 

함수에서는 값을 쥐고 있을 수 없지만 함수형 컴포넌트에서 hook이라는 것을 통해 이것이 가능해졌습니다. 그리고 우리는 아래와 같은 장점들을 얻게 됩니다.

 

1. 관심사 분리(UI 코드와 복잡한 state 관련 로직을 분리할 수 있게 됩니다)

2. 재활용성(분리된 hook은 다른 컴포넌트에서도 활용이 가능해집니다)

3. 테스트 용이성(hook이 분리되었기 때문에 UI와 붙어있던 때보다 덩치도 작아지고 복잡도도 낮아졌으므로 테스트에 대한 용이성이 증가합니다)

 

 

2. VS 다른 프레임워크(vue)

 

제가 vue를 다뤄보지도 않았고 이 부분에 대해선 직접 경험해 본 것이 없기 때문에 이 부분은 다른 분이 작성하신 블로그 내용을 참고해서 작성했습니다.

 

1. 진입장벽 및 범용성의 관점

    리액트는 UI 라이브러리이기 때문에 상당히 많은 부분을 개발자에게 직접 위임합니다. 대표적인 게 라우트이죠. 그러나 뷰의 경우, 빌트인 방식으로 많은 기능들을 default로 제공합니다. 대신 리액트의 경우 많은 모듈들이 존재합니다. 필요한 기능은 개발자가 직접 연결해서 사용하면 됩니다.

 

2. TS 지원 수준

    리액트에선 Typescript를 활용한 정적 표현이 매우 잘 되도록 되어있습니다. vue도 지원은 하지만 리액트와 비교했을 때 호환성 부분에서 아쉬운 부분이 존재합니다.

 

3. 트렌드

    얼마나 많은 사람이 사용하느냐도 무시할 수 없는 요소인데 리액트는 vue 대비 약 4배의 weekly 다운로드 수를 가지고 있습니다. (*15,337,624 / 3,372,604 = 4.5) 사용자가 많다는 것은 관련 모듈에 대한 지원성, 커뮤니티 활성화 등이 따라온다는 것이므로 이도 매우 중요합니다.

 

참고: 뷰와 리액트의 차이점: 관련 링크