[우아콘] 프론트엔드 상태관리 실전편을 보고 나서

상태관리 → 상태와 관리가 합쳐진 말

State: A Component’s Memory → 컴포넌트의 메모리가 상태이다

최근 리액트 개발에서 컴포넌트가 중심에 있음.

→ 어떤 팝업을 화면에 띄울지 말지, 주문/배달의 진행은 어떠한지

 

상태는 공통으로 그리고 단일로도 사용되어질 수 있는 개념임.

상태관리가 등장한지도 얼마 안됐는데 한계점도 있음

 

상태관리 방법의 변화

Redux로 상태관리를 풀고 있었고 → mobX등으로 해결을 해나가려고 했음

• 여전히 코드가 너무 많다는 문제가 있었지만 해결할 만한 방법 X → Post 상태관리, 원격 상태관리가 나옴
• 리덕스, mobx에는 스토어가 큰 것도 있지만 상태관리보다 API 호출 코드가 더 많다는 문제가 있음.
• Mobx + React-query 를 쓰니 스토어는 단순해졌음 → 컴포넌트가 대신 복잡해짐 → MobX는 여전히 복잡한 것 같고, 비즈니스 로직이 컴포넌트에 같이 있는 것 같다 → 그래서 Zustand를 활용해봄 

⇒ 특성에 맞춰서 상태관리를 해봄 → 클라이언트는 Zustand, 서버는 React Query를 통해서 해결

React Query

• TanStack Query → 공식문서에서 부터 강력한 비동기 처리를 해주는 관리 툴이다라고 적혀있음
• query → read, mutation → write, update
  
• Hook과 비슷한 사용성을 띄고 있다는 것을 알 수 있음.
• API Polling
  
• 아래의 과정을 하기 위에서 리덕스 같은 경우에는 위의 과정을 모두 직접 작성해줘야 되는 부분이 있음

Zustand

• 적은 보일러 플레이트 코드
• 직관적인 사용법
• 작은 패키지 사이즈

→ 이 모든게 리덕스에 비교했을 때 기준이라고 생각했을 때 리덕스가 얼마나 메인으로 자리잡았는 지 알 수 있지 않나 생각이 드는?

• Redux vs Zustand
  • 두 라이브러리가 모두 Flux 패턴으로 이뤄진
  • Zustand의 경우에는 처음 보더라도 바로 이해를 하고 사용할 수가 있음
  • 똑같은 패턴으로 만들어졌지만 Zustand는 Flux 패턴을 단순화 해둬서 쉽게 사용할 수 있음

왜 React Query와 Zustand를 도입하였는가

• Zustand: 컴포넌트의 로직이 복잡 → 에러, 성공 여부를 관리하는 부분이 많음 → 컴포넌트 밖으로 예제들을 뺴내야 하고 어쩌면 함수형으로 뺴내야 한다. → Flux를 쓰지만 쉽게 사용할 수 있고 Devtools도 사용가능
• React Query: API 호출 코드를 스토어에서 분리해냄 → React Hook과 유사, 자체 개발도구와 여러 인터페이 그리고 옵션을 제공해서 적은 코드로 강력한 동작이 가능하다.

상태관리는 프로덕트에 어떻게 녹아있을까?

• 서로 다른 조직에 서로 다른 개발자가 서로 다른 도메인을 개발했음 → 모든 도메인과 코드가 다양하고 다를 것이다. → 팀 내 표준 프로젝트라는 기준을 런칭

• 비즈니스 레이어와 스토어 레이어
  • 스토어 레이어 → zustand store와 react-query
  • 비즈니스 로직 → 비즈니스 계층에 대한 부분 + 서비스(특정 API의 Success, Error 헨들러, 로그 등에 대해서 - ex) A,B,C 주문에 대한 결과물?) → 일종의 헬퍼 function이 모여 있는 곳
• React Query를 쓸 때 어려운 것 → Key에 대한 값 → 변수를 고민 하는 것도 비용이다 → @lukemorales/query-key-factory

• Queries와 stores가 어떻게 상호작용하는지
  • 분홍색 → zustand store
  • 노랑색 → hook
  • 초록색 → Log 서비스 호출
  • 위의 컴포넌트만 봤을 때는 가독성이 좋아봉

• 페이지 → 컴포넌트 → hook을 호출 → Queries 와 stores 를 순서대로 호출 하게 됨

• 되게 간단한 지명 하나도 모든 걸 다 만들어야 할까?
  • 기준: 최상위 레이어에서 그 이하의 레이어만 불러올 수 있다?
  • 어떠한 페이지 → api 를 찔러서 리다이렉트 → hook와 컴포넌트가 낀다면 복잡해짐
  ⇒ 형식에 집중하지말고 본질에 집중해서 → 레이어 된 아키텍처를 쓰는 이유는 컴포넌트에 집중된 부분을 가독성과 유지 보수를 위해 레이어에 분산시키고 좀 더 효율적으로 사업성에 대응하기 위해서
  • 레이어를 통해서 책임을 분산 시킴으로써 기능을 확장할 때 hook와 store만 건드려서 관리가 가능하다

위와 같은 과정을 함으로써

1. Store는 클라이언트와 서버로 나뉘어서 관리
2. 컴포넌트는 각 레이어의 유기적인 결합
3. 프로덕트는 유연하고 변경하기 편한 구조로

무조건 도입 해야 하는가?

몇 년전만 해도 상태관리도 없었음 → 시장에서 서버나 이런 상태관리를 포함해 다 할 수 있는 부분이 없고 자바스크립트와 브라우저는 여전히 변하고 있음 → 현 시점에는? : 리액트 쿼리와 zustand를 통해 이를 처리하려고 함. → 로컬에 대한 부분도 활용을 하면서 글로벌 부분에 대해서는 클라이언트, 서버 등으로 나눠서 관리를 하는 방식으로 풀어나가는