23.02.23 - 상태 관리

1. 상태 관리

1) 전역 상태 관리

상태 : 변하는 데이터. UI에 동적으로 표현될 데이터를 말함. 

Side Effect : 함수(또는 컴포넌트)의 입력 외에도 함수의 결과에 영향을 미치는 요인. ex) 네트워크 요청, API 호출...

 

컴포넌트는 Side Effect를 최대한 배제하고 만들어야함. 입력이 가짜 데이터(fake data)라도 표현할 수 있어야 한다.

=> presentaion component

 

하지만 로딩중인 상태처럼 side effect에 의존적인 상태가 있을 수 있다. 애플리케이션을 만들때는 이러한 상황을 모두 고려해야함. 

 

 

 

 

(1) 리액트로 앱을 설계하는 방식

https://ko.reactjs.org/docs/thinking-in-react.html

React로 사고하기 – React

 

 

1단계 : UI를 컴포넌트 계층 구조로 나눈다. 

컴포넌트가 되어야 하는 것? => 단일 책임 원칙. 하나의 컴포넌트는 하나의 일만 해야한다. 

한 컴포넌트가 커질경우 보다 작은 하위 컴포넌트로 나눌 수 있다. 

컴포넌트를 나누면 계층 구조로 나열해본다. 

 

2단계 : React로 정적인 버전 만들기

데이터 모델로 UI만 렌더링되게 하는 정적인 버전을 만든다. 정적 버전을 만들때는 state를 사용하지 않아야 한다. 

간단한 예시는 하향식으로 만드는 것이 쉽지만 프로젝트가 커지면 상향식으로 만들고 테스트를 작성하면서 개발하는것이 더 쉽다. 

 

3단계 : UI state에 대한 최소한의, 그리고 완전한 표현 찾아내기

react는 state를 통해 값을 변경한다. 그러므로 UI를 상호작용하게 하려면 state를 사용해야하는데, 가능한 최소한의 state를 사용하고 나머지는 필요에 따라 그때그때 계산되도록한다. 

예시) TODO 리스트의 state = TODO 아이템을 저장하는 배열. TODO 아이템의 개수 = TODO 아이템 배열의 길이. 

 

4단계 : state가 어디에 있어야 할지 찾기

어떤 컴포넌트가 state를 변경하거나 소유할지 찾아야한다. React가 아래로 내려가는 단방향 데이터 흐름을 갖고있음을 유의해야 한다.

 

state의 위치를 결정하기 전에

• 이 state를 사용하는(영향 받는) 모든 컴포넌트를 찾는다
• 해당되는 컴포넌트들의 공통 소유 컴포넌트를 찾는다(해당되는 모든 컴포넌트들의 상위에 있는 하나의 컴포넌트)
• 공통, 또는 더 상위에 있는 컴포넌트가 state를 가져야 한다. 
• state를 소유할 적절한 컴포넌트가 없는 경우, state를 소유하는 컴포넌트를 만들어서 공통 소유 컴포넌트의 상위 계층에 추가한다. 

 

5단계 : 역방향 데이터 흐름 추가하기(state 끌어올리기)

계층 구조의 하단에 있는 컴포넌트에서 상위의 state 값을 변경해야할 수도 있다. 

이때는 state 끌어올리기를 사용할 수 있다. 상위의 컴포넌트가 setState() 함수를 props로 내려주고 하위의 컴포넌트에서 상위 컴포넌트의 값을 변경하도록 한다. 

 

 

 

 

 

(2) 상태의 두가지 구분

로컬

특정 컴포넌트 안에서만 관리되는 상태. 다른 컴포넌트와 데이터를 공유하지 않는 form 데이터가 예시. input box나 select box 등 입력값을 받는 경우. 

 

전역

프로덕트 전체 혹은 여러 컴포넌트에서 관리되는 상태. 다른 컴포넌트와 상태를 공유하고 영향을 끼친다. 

예시) 상품 선택 여부, 데이터 로딩 여부... 

 

서로 다른 컴포넌트가 사용하는 상태의 종류가 다를경우 => 전역상태일 필요는 없다. = 출처(sorce)가 달라도 상관 X

서로 다른 컴포넌트가 사용하는 상태의 종류가 같을 경우 => 반드시 출처가 같아야 함 = 전역상태여야한다.

 

 

 

 

 

(3) 전역상태에서의 데이터 무결성

데이터 무결성 : 데이터의 정확성을 보장하기 위해 데이터의 변경이나 수정 시 제한을 두어 안정성을 저해하는 요소를 막고 데이터 상태들을 항상 옳게 유지하는 것. 

 

=> 동일한 데이터는 항상 같은 곳에서 데이터를 가지고 와야 한다. Single source of truth(신뢰할수있는 단일 출처)

 

 

전역으로 상태를 관리해야 하는 경우

예시) 다크모드 / 라이트모드, 국제화(Globalization) 설정, Undo/Redo를 위한 history 기능

 

 

 

 

 

(4) 상태관리를 위한 툴 

React Content / Redux / MobX

전역 상태 저장소를 제공하고 props drilling 이슈를 해결한다.

 

상태 관리 툴이 반드시 필요한 것은 아니다. 그러므로 상태 관리의 기본기인 상태가 어디에 위치해야하는지를 먼저 파악해야 한다. 

 

 

 

 

 

2) Props Drilling

props drilling(프로퍼티 내려꽂기)

상위 컴포넌트의 state를 props를 통해 전달하고자 하는 컴포넌트로 전달하기 위해 그 사이는 props를 전달하는 용도로만 쓰이는 컴포넌트들을 거치면서 데이터를 전달하는 현상. 

 

 

문제점

props의 전달 횟수가 많지 않다면(5회 이내) 큰 문제가 되지 않지만, 규모가 커지고 구조가 복잡해지면 아래와 같은 문제가 발생한다. 

• 코드의 가독성이 매우 나빠진다
• 코드의 유지보수가 힘들어진다
• state 변경시 props 전달과정에서 불필요하게 관여된 컴포넌트들에도 리렌더링이 발생한다. => 성능에 악영향

 

 

해결 방법

• 컴포넌트와 관련있는 state를 가능한 가까이 유지하기
• 상태관리 라이브러리를 사용하기

 

 

 

 

 

---------------------------------------

 

로컬 상태 : 특정한 컴포넌트에서만 사용되는 상태. 다른 컴포넌트와 상태를 공유하지 않음.

전역 상태 : 모든 컴포넌트 또는 여러개의 컴포넌트가 사용하는 상태. 다른 컴포넌트와 상태를 공유하고 영향을 주고받음. 

 

전역상태가 필요한 이유

서로 다른 컴포넌트가 동일한 상태를 다룰경우 이 출처는 오직 한곳이어야 한다. 만약 출처가 여러개일 경우 상태가 변경될때마다 여러개의 출처를 모두 동기화시켜야 하고 구조가 복잡해지며 유지보수가 어렵다. 즉, 동일한 상태를 다루는 경우에는 동일한 출처를 사용하도록 해야하고, 이것을 전역 공간이라고 볼 수 있다.