[React]상태 관리

nada_1221·2022년 8월 31일
0

공부

목록 보기
46/49

상태 관리


프론트엔드 개발에서의 상태 관리.
React가 상태 관리를 위한 라이브러리는 아니다.
그러나 상태 관리의 주요 원칙을 배우고 이를 따라간다면, 컴포넌트 간 서로 느슨하게 결합된loose coupled, 구조적으로 아름다운 코드를 작성할 수 있다.

상태란 무엇인가?
UI에 동적으로 표현될 데이터

Side Effect란 무엇인가?
함수(또는 컴포넌트)의 입력 외에도 함수의 결과에 영향을 미치는 요인
대표적인 예: 네트워크 요청 (백엔드API요청)

React의 주요 개발 원칙 중 하나는 UI를 페이지 단위가 아닌 컴포넌트 단위로 보는 것이다.

리엑트로 사고하기 <-- 읽고가자

상태를 구분하는 데에는 절대적인 기준이나 법칙이 있는 것은 아니지만, 로컬 or 전역 상태로 나눠서 접근해보자.

로컬 상태는 특정 컴포넌트 안에서만 관리되는 상태이며, 전역 상태는 프로덕트 전체 혹은 여러가지 컴포넌트가 동시에 관리하는 상태를 말한다.

로컬 상태를 구분하는 것은 쉽다. 보통 컴포넌트 내에서만 영향을 끼치는 상태는 로컬 상태이다.

다른 컴포넌트와 데이터를 공유하지 않는 폼form 데이터는 대부분 로컬 상태이다.

input box,select box 등과 같이 입력 값을 받는 경우가 이에 해당한다.

전역 상태는 다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태이다.

서로 다른 컴포넌트가 사용하는 상태의 종류가 다르면, 꼭 전역 상태일 필요는 없다. 출처source가 달라도 된다.

Component A = wish list
Component B = profile data
/** Ok 상태의 종류(wish list & profile data) 가 다름**/

그러나, 서로 다른 컴포넌트가 동일한 상태를 다룬다면, 이 출처는 오직 한 곳이어야 한다. 만일 사본이 있을 경우, 두 데이터는 서로 동기화sync하는 과정이 필요한데, 이는 문제를 어렵게 만든다.

Component A = wish list
Component B = wish list copy
/** 서로 동일한 상태(wish list)를 다루는데 
서로 다른 출처(Component A & B)로 부터 가져오는 것은 피해야 한다.  **/

한 곳에서만 상태를 저장하고 접근해라. 여기서 하나의 출처는 다른 말로 이야기하면 전역 공간이라고 볼 수 있다.

데이터 무결성을 위해, 동일한 데이터는 항상 같은 곳에서 데이터를 가지고 오도록 하자. 신뢰할 수 있는 단일 출처Single source of truth 원칙은 프론트엔드 뿐만 아니라 다양한 곳에서 언급되는 원칙이다.

전역으로 상태를 관리해야 하는 경우는 어떤 것이 있을까?

네이버를 비롯한 여러 사이트에서 다크 모드 기능을 이용해 본 적이 있을 것이다. 이 경우 모든 페이지, 모든 컴포넌트에 다크 모드가 적용이 되어야 하기 때문에 이러한 테마 설정을 전역으로 관리할 수도 있다.

그리고 국제화 Globalization 설정도 마찬가지다.

사용자가 사용하는 브라우저나, 운영체제가 특정 언어를 사용하고 있음을 알아내서, UI에 필요한 텍스트 리소스를 따로 저장한 후, 전역 상태로 관리하기도 한다.

이 기능의 경우에도 모든 컴포넌트에서 사용자 언어로 표현이 되어야 하기 때문에 전역에서 상태 관리가 필요하다.

상태관리를 도와주는 각종 툴이 있다.
현업에서 쓰일 가능성이 매우 높으므로 상태 관리 라이브러리가 어떤 문제를 해결해주는 지만 알아보자.

  • React Context
  • Redux
  • MobX
  1. 전역 상태를 위한 저장소를 제공한다.
  2. 프로퍼티 내려꽂기 props drilling 문제를 해결한다.

상태관리 툴이 반드시 필요할까? 그것은 아니다. 상태 관리 툴이 없어도 충분히 규모 있는 애플리케이션을 만들 수 있다.

Props Drilling이란



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

Props Drilling의 문제점

Props의 전달 횟수가 5회 이내로 많지 않다면 큰 문제가 되지 않는다. 하지만 규모가 커지고 구조가 복잡해지면서 Props의 전달 과정이 늘어난다면 아래와 같은 문제가 발생한다.

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

해결 방법


과도한 Props Drilling을 방지하기 위한 방법으로는 컴포넌트와 관련있는 state는 될 수 있으면 가까이 유지하는 방법과 상태관리 라이브러리릇 ㅏ용하는 방법이 있다. 상태관리 라이브러리를 사용하게 되면 전역으로 관리하는 저장소에서 직접 state를 꺼내쓸 수 있기 때문에 Props Drilling을 방지하기에 매우 효과적이다.

profile
FE_개발자_지망생

0개의 댓글