본문 바로가기

FrontEnd

리액트 패턴 : Derived State - 파생(계산된) 상태 활용하기

반응형

원문 보기

상태 관리는 웹 애플리케이션을 구축하고 확장하는 데 있어 가장 어려운 부분입니다.
나는 개발자들이 주로 건전한 상태 관리 기계를 작성하는 일을 하며 돈을 받는다 생각합니다.
다른 모든 부분은 UI 라이브러리와 NPM 패키지를 사용하여 아웃소싱하거나 자동화할 수 있습니다.
 
이 포스트에서는 과소평가되고 있다고 생각되는 "파생 상태"라는 상태 관리 기술에 대해 다루고자 합니다.
많은 경우 상태 관리 논리를 단순화할 수 있습니다.
파생 상태 기술은 라이브러리에 구애받지 않으며 Redux, MobX 및 React의 built-in 훅에 적용할 수 있습니다.
 

파생 상태("Derived State")는 뭔가요?

이전에 정의된 상태들을 통해 계산할 수 있는 상태입니다.

이전 정보로 계산할 수 있는 정보는 상태에 넣지 않고, 필요한 상태들만 최소환으로 관리하는 것입니다.

변수를 상태에 저장하는 대신 계산하면 변경 사항이 발생할 때 데이터를 동기화 상태로 유지하는 것이 더 쉽습니다.

파생 상태의 예시

각 노래에 대한 checkbox으로 구성된 노래 selectir가 있다고 가정합니다.
노래는 장르별로 분류됩니다.
우리는 개별 노래와 전체 장르를 선택할 수 있기를 원합니다.

첫 번째 생각은 두 개의 상태 변수를 만드는 것입니다.

 

하나는 노래의 선택여부이고, 다른 하나는 장르의 선택 여부입니다.

간단해 보이지만 이것이 최선의 방법일까요? 이를 위해 두 개의 변수가 정말로 필요합니까?

이 예에서는 개별 노래 선택여부를 값을 기반으로 장르 선택여부를 파생할 수 있습니다.
아이디어는 다음과 같습니다.
  • 장르를 선택하면 장르 아래 노래들을 전부 선택합니다. 
  • 장르 input의 check 여부는 장르 아래 노래들이 전부 선택되었는지로 판단합니다.

장르 확인란의 체크 여부를 따로 저장할 필요가 없습니다.

장르 선택여부는 isGenreChecked 메서드와 songSelections 개체를 사용하여 계산됩니다.

장르는 그 아래에 있는 모든 노래가 선택된 경우에만 체크됩니다.
사용자가 장르 확인란을 클릭하면 해당 장르 아래의 모든 노래를 선택/선택 해제하기만 하면 됩니다.
 

파생 상태를 사용하는 이유는 무엇입니까?

상태를 동기화 상태로 유지하는 것이 훨씬 쉽습니다.
그 이유는 우리가 선택한 노래라는 단일 소스가 있기 때문입니다.
다른 모든 변수가 파생되는 동안 추적해야 하는 단일 상태 변수가 있으면 상태 추적이 쉽습니다.

 

예를 들어, 각 노래의 선택을 취소할 때 더 이상 상위 장르의 상태를 업데이트하는 것에 대해 걱정할 필요가 없습니다.
새 렌더링에서 앱은 장르의 상태를 다시 계산하고 자동으로 선택을 취소합니다.

 

성능 문제

각 렌더에서 상태 변수의 값을 다시 계산하는 것과 관련한 성능 문제가 있을 수 있습니다.
즉, 파생된 상태의 계산 복잡성에 따라 실제로 성능 오버헤드가 있을 수 있습니다.
눈에 띄는 성능 저하를 보이면 useMemo를 사용합니다.

 

마무리

이 포스트에서 우리는 "Derived State"라는 상태 관리 최적화 기법을 다루었습니다.
"Derived State"는 상태에 저장해야 하는 변수의 수를 줄여 코드를 단순화하는 데 도움이 됩니다.

 특정 상태 변수가 상태에 저장되지 않고 즉석에서 계산될 수 있는지 여부를 확인합시다.

반응형