React State Management

첫 회사에서 19년도에 처음 React를 사용했었다.

 

처음 혼자 공부 하면서 찾아 봤을 때 Apollo GraphQL을 사용했어서 Apollo Client를 사용했었고, 16.8에 React Hooks 개념도 처음 나와서 사람들이 굉장히 열광 했었는데 뭔지 잘 모르겠었고 componentDidMount, setState등 귀찮아 보이는거 대신 간단하게 useState와 useEffect를 사용하면 쉽다고해서 바로 공부하고 사용했었다.

 

당시에도 GraphQL과 Serverless 처음 접하는 기술이 많아서 전역 상태 관리로 유명했던 Redux까지 기술 스택에 포함 시키기엔 러닝커브가 있었고 다음에 하는게 좋겠다 싶었고 마침 많은 유튜버들이 ContextAPI가 Redux를 대체할까? 라는 제목의 유튜브가 많아서 쉽게 사용해보자 하고 했었다.

 

지나고 이번 기술스택을 정할때 보니 https://velog.io/@dldngus5/TILReact-%EC%83%81%ED%83%9C%EA%B4%80%EB%A6%AC-%EA%B3%A0%EB%AF%BC-Context-Recoil

[TIL][React] 상태관리 고민 (Context, Recoil)

https://velog.io/@chosh/%EB%A6%AC%EC%95%A1%ED%8A%B8%EC%97%90%EC%84%9C%EC%9D%98-%EC%83%81%ED%83%9C%EA%B4%80%EB%A6%AC-Context-vs-Recoil-vs-Redux

TIL 030 리액트에서의 상태관리 Context vs Recoil vs Redux

 

Context API의 모든 구독 컴포넌트가 다시 랜더링 되는 문제가 있고 Recoil은 비슷하게 쉽게 사용할 수 있어서 크게 거리낌 없이 Recoil을 선택했던거 같다.

 

React Query는 Apollo Client와 비슷한 느낌이었고 Cache를 사용해서 API관련 상태들을 관리하는 state management tool 이었다.

우선 잘 모르겠으니 다른회사에서 잘 사용하고 있는 기술 스택을 가져와보자가 컸었다. SWR은 이야기도 나오지 않았지만...

 

Vue + Vuex에서는 필요한 경우에 탭을 이동하거나 기타 경우에 다시 호출하고 싶은 경우가 있었는데 직접 함수를 구현해서 사용하고, 필요한 경우 Watch를 통해 재호출 했었다.

React Query를 사용해보니 `다 만들어 놨으니 쓰기만 해` 라는 느낌이 들 정도로 key를 지정하거나 cacheTime, staleTime, isFetching, isLoading, isSuccess 등 vue 에서와 다르게 모든 팀원들이 어느정도 React Query를 쓰고 있다는걸 아니 까먹지 않고 에러처리나 로딩처리를 할 수 있었다.