State management - 상태관리

💡 상태?
웹 애플리케이션의 시간이 지남에 따라 혹은 상호작용에 의해 변화할 수 있는 데이터

상태관리?

- 유저와의 상호작용을 위해, 상태를 조작하고 다루는 모든 작업

상태관리가 중요한 이유?

- 상태관리는 컴포넌트의 불필요한 리렌더링을 방지하고 의도하지 않은 UI/UX를 방지하며 앱의 유지보수성을 높입니다. 

 

과거 jQuery를 사용하던 시절 데이터 속성(dataset)을 이용해서 상태관리를 수행했는데, DOM 중심의 상태 관리로직을 구성하게 되므로, 상태 변화의 추적이 어렵다는 단점이 존재합니다.

<div id="div1" data-num="1">dataset</div>

<script type="text/javascript">
	document.getElementById("div1")['data-air'] = 24;
</script>

 

추후, SPA 프레임워크 앵귤러, 뷰, 리액트의 등장으로 DOM 접근 없이 데이터가 변경되면 출력도 자동으로 변경되도록 처리가 가능해졌으며, 데이터 중심의 상태관리 로직의 구성이 가능해지고 이는 상태가 어디서 변화했는지 추적에 용이합니다.

---

리액트의 상태관리

단방향 데이터 바인딩

• 컴포넌트 내부

JavaScript(Model)에서 HTML(View)의 단방향으로 데이터 동기화가 일어납니다.
단방향 데이터 바인딩으로 인해 HTML(View)에서 JavaScript(Model)로의 상태 업데이트가 불가능하므로, 
이벤트 핸들러 등을 통해 상태 업데이트를 수행해야 합니다.

• 컴포넌트 간(상위 컴포넌트 -> 하위 컴포넌트)

상위 컴포넌트의 state를 하위 컴포넌트의 props로 전달합니다.
단방향 데이터 바인딩은 애플리케이션의 데이터 흐름을 예측하기 쉬워 디버깅이 용이합니다.

리액트는 단방향 데이터 흐름을 가지고 있으므로 컴포넌트가 복잡해질 경우, 상위 컴포넌트에서 하위 컴포넌트로 Props를 전달해야 하는 Props Drilling이 발생하는데, 이는 중간 컴포넌트의 불필요한 리렌더링을 발생시켜 유지보수성과 웹 성능을 저하시킵니다.

이처럼 애플리케이션의 규모가 커짐에 따라 상태관리가 복잡해지므로 효율적인 상태관리는 버그를 줄이고 애플리케이션을 보다 예측 가능하게 만들 수 있습니다.

💡 양방향 데이터 바인딩
HTML(View), JavaScript(Model) 사이의 ViewModel에 의해 하나로 묶여 View, Model 둘 중 하나만 변경되어도 함께 변경

전역 상태 관리

Redux

• 특정 상태로 인한 컴포넌트 간의 의존성을 분리할 수 있습니다.
• 컴포넌트 상태 업데이트 로직을 다른 파일로 분리해 효율적인 상태관리가 가능합니다.
• 여러 컴포넌트를 거쳐 데이터를 전달할 필요없이 손쉽게 상태값을 전달하고 업데이트 할 수 있습니다.
• Provider의 생략으로 렌더링 트리를 최소화하고 순수 함수로서 동작하는 Reducer를 통해 예측 가능한 상태관리를 보장합니다.
• Devtools를 제공하여 보다 손쉽게 상태관리와 디버깅이 가능합니다.
• 다만, 상태 변경을 수행하는 리듀서와 액션 타입을 정의하는 등 많은 보일러 플레이트 코드를 요구하고 러닝커브다 높다는 단점이 있습니다.

Redux 구조

Actions

상태 업데이트가 필요하면 액션이 발생하고 디스패치 되어 스토어에 전달된다.
액션 객체에는 type 프로퍼티가 반드시 있어야한다.

Reducer

리듀서는 상태 업데이트를 수행하는 함수이다.
현재 상태와 전달받은 액션 객체를 파라미터로 받은 다음 상태와 액션의 타입을 참고해 새로운 상태 객체를 반환한다.

Store

스토어 안에는 현재 애플리케이션 상태와 리듀서가 들어있다.
애플리케이션은 단 하나의 스토어만 가질 수 있다.

Dispatch

디스패치는 스토어 내장함수 중 하나이다.
액션을 파라미터로 받고 스토어에 전달한다.
디스패치 함수가 호출되면 스토어는 리듀서 함수를 실행해 새로운 상태를 반환한다.

무분별한 전역 상태는 지양하자