리액트는 왜 상태를 직접 수정 하지 않고 새로운 상태 객체를 수정할까? - 리액트의 불변성 이야기
해당 포스트는 이전 state를 사용하는 이유를 공부하다가 생긴 의문을 공부하다가 다시 생긴 의문점을 작성한 내용입니다.
글은 읽지 않아도 앞으로 작성할 포스트 내용과는 무관합니다!
2024.09.04 - [Develope/REACT] - 리액트는 왜 State를 사용할까?
리액트는 왜 State를 사용할까?
리액트를 사용하는 와중, 가장 흔히 쓰지만 왜 이렇게 쓰는지 궁금했던게 하나 있다.바로 리액트 훅 중의 한개인 state이다. 리액트는 자바스크립트의 라이브러리다. 그렇기 때문에, 리액트의
deer-develope-diary.tistory.com
다시 State의 특징에 대해
이전 포스팅과는 크게 관련되지 않는 것 같아 제외한 내용이었지만, state에 대해 공부하다가 알게 된 것은 state로 선언된 값은 직접적인 값을 변경하는 것이 아니라 복사 된 상태를 변경한다는 특징을 가지고 있다는 것이다.
state는 직접적인 요소를 변경하지 않고 가상 복제본을 사용하여 상태를 관리하는데, 리액트의 불변성과도 직접적인 연관이 있다고 생각한다. 사실 state를 직역하면 '상태'라는 뜻이잖는가?
그래서 리액트 불변성이 뭔데?
리액트는 실제 화면이 로드될 때 생성된 DOM이 아니라 가상DOM(Virtual DOM)의 상태를 관리한다. 다시 말해, 상태가 변경 되면 실제 DOM이 아닌 가상 DOM의 상태를 변경하여 DOM을 직접적으로 수정 하지 않고 가상DOM을 수정한 뒤 원본과 비교한 뒤 변경된 부분만 커밋하여 다시 웹 화면에 적용시키는 것이다.
조금 더 자세히 설명하자면, 리액트는 상태 관리와 웹 화면 변화를 표현하기 위해 state 값이 변경 될 때 마다 화면을 리렌더링 한다.
렌더링 과정
사실 지난 포스팅에서 많이 쓴 단어가 있다면 아마 state 다음으로 '리렌더링'이라는 단어일 것 같다.
리렌더링이 뭔지 몰라도 문맥 상 대충 새로 고침 된다는 뜻 같은데 그렇다면 과연, 렌더링은 무엇일까?
렌더링은 HTML, CSS, Javascript가 해석되고 실행되어 우리 모니터에 웹 화면이 뜨는 과정과 결과를 말한다.
그렇다면 우리는 어떻게 화면을 볼 수 있는 걸까?
- 주소 검색창에 URL을 작성하면 서버로부터 HTTP 요청을 통해 해당 HTML 문서를 URL 로부터 가져온다.
- HTML의 정보를 해석하고 가져와 이를 통해 DOM(Document Object Model)이라는 노드 기반 트리 구조를 생성한다.
- CSS의 정보도 해석하고 가져와 이를 통해 CSSOM(CSS Object Model)이라는 트리 구조를 생성한다.
- DOM과 CSSOM을 결합하여 페이지를 렌더링 하는데 필요한 정보를 취합한다.(렌더 트리 생성)
- 렌더 트리를 통해 브라우저 화면의 어느 곳에 나타나야 하는지 정확하게 계산한다. (레이아웃)
- 레이아웃 단계를 거친 노드들에 스타일을 각 요소에 적용한다. (페인팅)
- 레이아웃과 페인팅 과정이 끝나면 이 과정을 통하여 화면이 모니터에 나타나게 된다.
위와 같은 과정을 거쳐 우리는 화면을 볼 수 있는데, 만약 리액트에서 버튼을 한개 눌러서 숫자를 1에서 2로 변경하는 그 과정마다 화면 전체에 리렌더링이 일어나 DOM이 변경 되고, 다시 레이아웃 단계를 거쳐 페인팅 과정을 거쳐 웹을 우리 화면에 띄운다면 어떻게 될까? 브라우저와 서버에겐 엄청난 부담이 갈 것이다. 이러한 문제를 리액트는 가상 DOM을 사용함으로써 해결했다.
리액트의 장점을 지켜주는 가상 DOM
리액트 가상DOM은 상태 변화가 일어날 때 HTML을 통해 만들어진 DOM이 아니라 가상 DOM을 수정하고 비교하여 상태 변화가 일어난 부분만 리렌더링이 일어나도록 도와주며 성능을 최적화 시킨다.
리액트의 장점
1. 리액트의 state는 리렌더링을 야기하여 즉각적인 화면 변화를 보여준다.
리액트는 setState를 통해 state 값을 변경하고, state가 변경 될 때마다 화면을 리렌더링 시킨다. 이런 state 변화를 통해 리렌더링이 될 때마다 다시 DOM을 만들고 레이아웃 하고 페인팅 하지 않도록 우리는 가상 DOM만을 변화 시켜 기존 DOM과의 비교 후 수정된 부분만 리렌더링하여 리액트 성능을 최적화 시키며 빠른 변화를 볼 수 있게 해준다.
2. 리액트는 SPA다.
SPA는 Single Page Application으로 한개의 HTML만을 사용하며 라우팅 될 때 헤더나 사이드를 제외하고 대부분의 요소를 삭제하고 다시 수정하여 생성하여 화면이 깜빡이지 않고 자연스럽게 이동하는 것처럼 보인다.
SPA의 장점.
- 라우팅 될 때마다 화면이 새로 그려질 필요가 없어 페이지 로드가 빠르다.
- 새로운 페이지 요청 시 이미 받은 서버 리소스를 이용하기 때문에 서버 리소스를 적게 사용할 수 있다.
결론: 리액트에서 상태를 직접 수정하지 않는 이유
리액트에서 상태를 직접 수정하지 않는 이유는 불변성을 유지하고 성능을 최적화 시키기 위함이다.
상태가 변경될 때마다 가상 DOM을 이용하여 기존 DOM과 비교한 후 변경된 부분만 수정하여 리렌더링 하기 때문에 서버와 클라이언트에 부담을 덜어주면서 리액트의 장점을 최대화 시켜준다.