React.js 의 상태를 임의로 변화하지 말아야 할 이유

강의를 보던중 Never mutate your state directly 라는 문구가 들려서 한번 검색을 해보았다.

당연히 React에서는 this.setState로만 우리의 state를 변경하는 것으로 배웠고,

기본적으로 하지않는 이유는 setState를 사용하지 않고, state만 변경 했을시

즉각적으로 웹브라우저에 변경이 보이지 않는다. ( Rerender 하지않는다. ) 라는 이유 때문이었다.

 


Rerender의 문제 말고 왜? State를 변경하지 말라는 것일까

2가지의 이유가 있다.

 

a.) setState works in batches, which means one cannot expect the setState to do the state update immediately, it is an asynchronous operation so the state changes may happen in later point in time which means manually mutating state may get overriden by setState.

 

-> setState는 비동기식 작업이기 때문에 우리가 임의로 수정한 state가 후에 , 비동적 작업이 끝난후, setState에 의해

새로운값 ( 재정의 ) 가 이루어져 원하는 값을 뽑을 수 없다.

 


b.) Performance. When using pure component or shouldComponentUpdate, they will do a shallow compare using === operator, but if you mutate the state the object reference will still be the same so the comparison would fail.

 

-> 성능 때문이다. 우리가 순수 컴포너트나 shouldComponentUpdate 매서드를 이용할때, 얕은 비교를 === 연산자를 이용하여 수행하는데, 만약 state의 주소를 변경해도, 객체는 동일한 주소를 유지하고 있어 비교에 실패한다.

 

설명을 좀 추가하자면,

순수 컴포넌트는 리턴이 immutable 한 컴포넌트인데,

순수 컴포넌트에는 shouldComponentUpdate가 기본적으로 들어가있어, 컴포넌트의 변화가 있어야 리렌더를 하게,

얕은 비교를 수행한다. ( === 연산자로 )

 

그런데, 만약 state의 상태를 변화하면 주소가 달라지므로 계속 리렌더를 수행하게 되는 문제가 생긴다는 것이다.

그래서 Rerender를 수행 하지 않아도 되는 객체에 ( pure Component 나 shouldComponentUpdate가 사용된 컴포넌트 )

지속적인 ReRender를 요청하는 성능적 이슈가 있다는 것이다.

 

state를 임의로 바꾸는 짓은 하지않았을 테지만, 하지말라는 이유를 알아야 된다고 생각하기에 포스팅 해봅니다!

Comment