상태관리란? In FrontEnd

LOCA·2023년 10월 26일
0

리액트

목록 보기
2/3

1. 상태란 ?

"유저와의 상호작용을 위한, 변할 수 있는 데이터"

우리팀이 만든 핍포같은 경우도 간단한 마이 페이지 지만,

유저의 프로필이미지, 아이디 주소 닉네임 값등, 유저에게 눈에 보이는 데이터들은 전부 상태라 할수 있다.

이것만 상태냐 ?

눈에 보이지는 않지만, 로딩스피너, 해당 기능등을 작동하기 위해 숨겨진 어딘가에 저장되어 있는 데이터들도 전부 상태라고 할 수 있다.


2. 즉, 상태관리란 ?

유저에게 UI / UX 를 제공하고.
유저와 데이터를 주고받는다.
"유저와의 상호작용을 위해, 상태를 조작하고 다루는 모든 작업" 이다.


3. 상태관리는 왜 중요할까 ?

서비스가 방대해지고 하는 역할들이 많아지면 ,
상태가 언제? 어디서 ? 왜 변했는지 추적하기 힘들어진다.


4. 과거의 상태관리


과거에는 HTML의 데이터 어트리뷰트를 사용하여 돔 element에 상태를 직접 주입하여 사용하였다.
-> 추적의 어려움 -> 유지보수의 어려움


5. 현재의 상태관리


서비스의 고도화로 유저들의 눈높이도 향상됨.

유저들의 니즈에 맞춰 SPA가 등장하였고, 현재 주메타가 되었다.


6. 리액트의 상태관리

리액트는 양방향의데이터흐름을 가지는 MVC와 달리
단방향의 데이터 흐름을 가진다.

상위 컴포넌트에서 State를 가지고 해당 상태를 저장하면서
의존된 컴포넌트가 있다고하면 props로 해당상태를 넘기게 된다.

그런데 의존된 컴포넌트가 많다면 ...?

이문제는 상태가 어디서 언제 왜 변경되었는지 추적하기 힘들어진다.
이문제를

이라고 부른다.

props Drilling을 해결하기위해 두둥


7. 리덕스

리덕스의 등장!

리덕스는 Flux 아키텍처와 Reducer의 개념을 합쳐서 만든 전역 상태관리 라이브러리다.
전역상태관리로 상태관리를 하다보니

  1. 의존되는 컴포넌트들을 분리할수 있게되었고
  2. 리덕스 데브툴스라는 강력한 개발도구를 지원하기에
    이를 통해 상태가 어디서 언제 왜 변경되었는지 알기 쉬워졌다.

이것만 들으면 모든 문제가 해결 되었다고 생각할 수있다.
그래서 실제로 많은 서비스에서 리덕스를 사용해서 상태관리를 하고 있었다.

다만 리덕스의 치명적인 단점이 존재했다.

  1. 리덕스를 사용하기위해 많은 코드를 작성해야하는 수많은 보일러플레이트 코드가 있었다.
  2. API 통신 관련 코드를 전역적으로 관리하게되는 상황을 피하지 못하게 되었다.

개발자들은 항상 이러한 단점들을 개선하고 싶어한다
그 후
대 상태관리 라이브러리 시대가 도래하였다.


8. 상태관리 라이브러리의 시대

수많은 상태관리 라이브러리들이 등장하였다.
Mobx,Zustand,Recoil,ReduxToolkit,Zotai,SWR,ReactQuery 등!!!

이렇게 많은 라이브러리가 있는데, 우리는 마냥 좋기만 한가

어떤 상태관리라이브러리를 쓸지, 뭘쓰는게 우리프로젝트에 적합한지 오히려 혼란만 야기되었다.
여기서 우리는 프론트엔드 개발자로써, 본인이 상태관리를 할 때
본인의 주관과 관점을 가져야 한다.


9. 좋은 리액트 상태관리란 ?

일반적인 리액트의 상태관리는 지역적인 상태관리로 지역적인상태를 가지고있는데
이는 props drilling을 발생시킬수 있다.
하지만 해당 props drilling을 해결하기 위해서 무조건 전역상태관리로 빼는게 좋을까 ?
아니다. 그것보다는 합성컴포넌트를 적절히 사용해서 props drilling을 간단히 해결 하는 것도 좋은 방법일수 있다. 재사용도 물론 함께 따라온다.

리덕스를 이용하면서 리덕스의 API통신코드를 전역상태에 저장한 경험이 있을거다.
thunk, saga등을 이용하여. 이때 명확한 전략이 없다면,
언제 이 데이터들을 refresh해야할지 파악이 힘들 수 있다.
서버데이터를 전역상태에 저장하는것을 데이터를 캐싱한다고 하는데,
어떤 시점에 이 데이터들을 동기화 시켜야할지 전략이 없다는 것은
전역상태에 있는 데이터가 항상 최신값을 바라보지 않을 수 있다.
이때 React Query, SWR같은 라이브러리를 똑똑하게 활용 한다면 더 좋은 API 통신 코드가 될수 있을 것이다.

상태관리를 하면서 하나의 컴포넌트가 너무 많은 상태를 가지고 있고,
해당 상태를 모드 props로 넘기고 있다면, 이거를 전역상태관리로 빼야지 하는 생각보다는
해당 컴포넌트가 너무 많은 일을 하고 있는 것은 아닌지, 생각을 해보고 응집도를 높이는게 좋을것 같다

참고자료
우테코 테코톡 온스타님의 상태관리
https://www.youtube.com/watch?v=jqir73Lourk

profile
helloWorld

0개의 댓글