상태관리

프론트엔드 상태관리 방법의 변화

• 초기에는 리덕스를 주로 사용함
• 리덕스 모빅스를 사용하더라도 코드가 길다는 문제점이 있었음
• store가 너무 크고 복잡함
  • store에 상태관리보다 api 호출 코드가 더 많다
  • reduxsk 모빅스가 상태관리보다 api 호출용으로 더 많이 사용하게 됨
• 리액트 쿼리 도입 후
  • 스토어는 간단한데 컴포넌트가 복잡해짐
  • 비즈니스 로직이 대부분 컴포넌트에 집중되어 컴포넌트가 복잡해지는 문제가 생김
• 해결방법
• 클라이언트가 관리하는 : zustand
• 서버 상태 관리: 리액트 쿼리

리액트 쿼리

• 공식문서: 비동기 상태관리 도구
• 쿼리: read / 뮤테이션: create, update, delete
• 리덕스 vs 리액트 쿼리
  • api 호출 코드에 polling을 구현하려면?
    • 리덕스 : 액션선언, 스테이트 추가, 리듀서 대응, 사가 폴링 겨현, 컴포넌트 연결
    • 리액트쿼리 : 쿼리 선언, 옵션
    • 리액트 쿼리에서는 isfetching, isloading, isSuccess등의 옵션을 사용
• 장점
  • 에이피아이 코드로 비대해진 스토어를 목적에 맞게 분리
  • 리액트 훅과 비슷한 직관적인 사용성
  • 여러 인터페이스와 옵션을 제공해 적은 코드로 강력한 동작
  • 자체 개발도구 제공
• 팁
  • usequery 대신에 querycache를 사용하면 좋다

zustand

• 적은 보일러 플레이트 코드, 직관적인 사용법, 작은 패키지 사이즈
• flux패턴을 단순화해서 만들어짐
• 장점
  • 컴포넌트 밖에서도 상태 변경이 가능
  • 사용성이 단순해 러닝커브가 낮음
  • 상태관리에 필요한 코드도 적음
  • 리덕스 데브툴스 확장 프로그램 활용 가능

상태관리 툴이 어떻게 프로젝트에 적용되었는지

• 컴포넌트 로직 레이어 분리
• 장점
  • 컴포넌트 코드 짧아짐
  • 비지니스 로직이 역할에 맞게 분산
  • 컴포넌트의 동작 유츄와 로직 파악이 용이해짐