[TIL] 상태 관리에서의 불변성

1. axios 요청해서 받은 data를 바로 data에 조작하지 말 것!

ex)

...
        setRows(
'이 data =>' data.resData.content.map((item: FaqRes) => ({
            ...item,
            isFrequency: item.isFrequency ? '적용' : '미적용',
            createdAt: formatToKSTDateTime(item.createdAt as string),
            creator: `${item.creatorName}/${item.creatorEmail}`,
          }))
        );
...

2. spread 문법을 사용하면서 똑같은 배열을 왜 만들어서 활용하는지 궁금함이 생겼다

React에서는 상태를 직접 변경하는 것이 아니라, 상태의 복사본을 만들어 수정한 후 그 복사본으로 상태를 업데이트하는 것이 중요한 원칙이라고 한다.

왜 불변성을 유지해야 하나요?

성능 최적화: React는 상태가 변경될 때마다 컴포넌트가 다시 렌더링됩니다. 상태가 직접 변경되면 React는 변경된 부분을 감지하지 못할 수 있습니다. 하지만 불변성을 유지하면 React는 상태 변경을 정확하게 감지할 수 있습니다.

예측 가능성: 상태를 직접 변경하면 예상치 못한 부작용이 발생할 수 있습니다. 불변성을 유지하면 상태 변경이 명확하게 관리되므로 코드의 예측 가능성이 높아집니다.

디버깅 용이: 불변성을 유지하면 상태 변경 전후를 비교하기 쉬워지고, 상태 추적이나 디버깅이 더 쉬워집니다.

그럼 모든 경우에 복사본을 생성해서 불변성을 유지해야 할까?

그건 아니다.

대표적으로

1. 로컬 변수:
   함수 내부에서 사용되는 로컬 변수나 객체는 불변성을 유지할 필요가 없습니다. 이들은 함수가 실행될 때 생성되고, 함수가 끝나면 메모리에서 해제되기 때문에 불변성을 강제할 필요가 없습니다.
2. 성능이 중요한 경우:
   큰 배열이나 객체를 반복적으로 처리해야 하는 상황에서는 불변성을 유지하려면 성능에 부담이 될 수 있습니다. 이럴 때는 불변성을 유지하지 않고, 직접적으로 변경하여 성능을 최적화할 수 있습니다. 하지만 이는 상황에 따라 신중하게 판단해야 합니다.

이러한 경우에는 불변성을 유지하지 않아도 된다.

요약: 불변성을 유지하는 기준

• 상태 관리: React 상태나 Redux 상태와 같이 변경이 감지되어야 하는 경우, 불변성을 유지해야 합니다.
• 로컬 작업: 함수 내부의 로컬 작업이나 불변성을 유지할 필요가 없는 곳에서는 불변성을 강제하지 않아도 됩니다.
• 성능 고려: 성능이 중요한 경우 불변성을 포기할 수 있지만, 그에 따른 부작용을 충분히 고려해야 합니다.