강연자 : 우형 주문프론트팀 배민근

제목: React Query와 상태관리

FE 상태관리

• 라이브러리가 먼저 떠오르는 현실 (Redux, MobX, Recoil 등)
• 상태란?
  • 주어진 시간에 대해 시스템을 나타내는 것.
  • 언제든지 변경될 수 있다.
  • 즉, 문자열, 배열, 객체 등의 형태로 응용 프로그램에 저장된 데이터를 상태라고 한다.
  • 개발자 입장에서는 관리해야하는 데이터들 (지멋대로 놔두면 안되는 데이터들)
    • 모던 웹프론트엔드 개발
      • UI/UX의 중요성과 함께 프로덕트 규모가 커지므로 FE애서 수행하는 역할이 많아짐
      • 즉, 점점 더 관리하는 상태가 많아지고 있다.
• 그럼 상태관리란?
  • 상태를 관리하는 방법에 대한 것. (프로덕트가 커짐에 따라 어려움도 커진다.)
  • 상태들은 시간에 따라 변화한다.
  • React에서는 단방향 바인딩이라 Props Drilling 이슈도 존재한다.
    • Redux, MobX같은 라이브러리를 활용해 해결할 수도 있다.

1. 주문프로덕트 팀에서 상태관리를 하면서 생긴 경험

• redux로 fetch했었음.

• 스토어가 전역 상태의 관리보다는 점점 API 통신 코드로 변화해감.

• 여기서 다 관리하는게 맞나? 라는 의문을 가지게 됨

  • API 통신 관련 코드가 모두 Store에?
  • 상태마다 반복되는 isFetching, isError 등 API 관련 상태가 반복됨.
  • 이렇게 반복되는 비슷한 구조의 API 통신 코드

• 서버에서 받아야하는 상태들의 특성에 대해 분석해봄

  • 클라이언트에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지되는 것
  • fetching이나 updating에 비동기 api가 필요한 것
  • 다른 사람들과 공유되는 것으로, 사용자가 모르는 사이에 변경될 수 있는 것
  • 신경 쓰지 않는다면, 잠재적으로 out of date가 될 가능성이 있는 것
  • 다른 시각으로 보면 state들이 일종의 ‘캐시’라고 생각해볼 수 있다. 암튼.

• 상태는 이제 2개로 나눌 수 있다.

  • Client State
    • Client에서 소유하며 온전히 제어가능하다.
    • 초기값 설정이나 조작에 제약사항이 없다.
      • 다른 사람들과 공유되지 않으며, Client 내에서 UI/UX 흐름이나 사용자 인터렉션에 따라 변할 수 있다.
      • 항상 Client 내에서 최신 상태로 관리된다.
      • Ownership이 Client에 있다.
  • Server State
    • Client에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지된다.
    • Fetching/Updating에 비동기 API가 필요하다.
    • 다른 사람들과 공유되는 것으로 사용자가 모르는 사이에 변경될 수 있다.
    • 신경 쓰지 않는다면 잠재적으로 out of date가 될 가능성이 있다.
    • Ownership이 Server에 있다.

• 그래서 react-query를 선택했다.

react-query

• server state를 fetching, caching, synchronizing, updating 해주는 라이브러리이다.