BKJang / dev-tips

📚 This repository is a collection of development tips and troubleshooting I have experienced during development.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

React의 state는 왜 불변성을 유지해야할까? 왜 Immutable.js 를 사용할까?

BKJang opened this issue · comments

❗️ React의 state는 왜 불변성을 유지해야할까? 왜 Immutable.js 를 사용할까?

reactredux의 공식 문서를 읽다 보면 Immutability를 강조하는 대목을 종종 볼 수 있다.
왜 불변성(Immutability)를 유지해줘야 할까?

불변성을 지키지 않으면 우리는 컴포넌트를 최적화 할 수 없다.

리액트가 컴포넌트를 렌더링하는 과정을 살펴보자.

  1. setState를 호출 (혹은 부모로부터 props를 전달 받음)
  2. shouldComponentUpdate를 실행했는데 false를 리턴하면 여기서 멈추고, true를 리턴하면 다음 단계로 이동
  3. 가상 DOM과 실제 DOM을 비교해서 변경사항이 있으면 화면을 다시 그린다

핵심은 2번에 있다. 다음과 같은 2개의 상태를 비교한다고 가정해보자.

const array = [1,2,3,4];
const sameArray = array;
sameArray.push(5);

console.log(array !== sameArray); // false
const array = [1,2,3,4];
const differentArray = [...array, 5];
console.log(array !== differentArray); // true

첫 번째 코드의 arraysameArray변수가 참조하고 있는 배열의 주소 값은 서로 같다. 하지만, 두 번째 코드의 각각의 배열은 다른 레퍼런스를 가지기 때문에 비교했을 때 다르다는 결과 값이 나오게 된다.
이와 같이 불변성을 유지하여 코드를 작성하면 각 객체의 값이 아닌 레퍼런스 값만 비교를 해주면 된다.

즉, shouldComponentUpdate내의 코드는 한 줄이면 컴포넌트를 최적화할 수 있게 된다.

하지만, 불변성을 유지하며 코드를 작성하다보면 상태 업데이트 로직이 복잡해질 수 있다.

state = {
    where: {
        are: {
            you: {
                now: 'faded',
                away: true // 이 부분을 바꾸고 싶다
            },
            so: 'lost'
        },
        under: {
            the: true,
            sea: false
        }
    }
}
const { where } = this.state;
this.setState({
    where: {
        ...where,
        are: {
            ...where.are,
            you: {
                ...where.are.you,
                away: false
            }
        }
    }
});

위의 예시만 봐도 충분히 복잡해지는 것을 볼 수 있다. 이런 상태 업데이트 로직을 편하게 해주는 대표적인 라이브러리가 우리가 React를 사용하면서 패턴 처럼 많이 사용해왔던 Immutable.js이다.

정리하자면, React의 상태는 컴포넌트 최적화를 위해 불변성을 유지해야하며 이를 편하게 하기 위해 Immutable.js같은 불변 객체를 반환해주는 라이브러리를 사용한다.

🙏 Reference

안녕하세요, 불변성 관련 글을 읽다가 찾아오게 되었습니다.
작성해주신 글에 질문이 있어서 이렇게 댓글을 남깁니다.


불변성을 유지하여 코드를 작성하면 각 객체의 값이 아닌 레퍼런스 값만 비교를 해주면 된다.
즉, shouldComponentUpdate내의 코드는 한 줄이면 컴포넌트를 최적화할 수 있게 된다.


레퍼런스 값 이외 내부 값을 비교해주면 비용이 더 커지기 때문에
레퍼런스 값만 비교해서 변경을 확인할 수 있다면 컴포넌트 최적화가 되었다고 하는건가요??

즉, 레퍼런스 값만 비교하면 되기 때문에 최적화가 되었다는 말씀이신가요??

답변 부탁드리겠습니다. 감사합니다.