React의 전역 상태 관리 라이브러리에 대한 질문 모음

1. redux 와 recoil 이 데이터를 저장하는 방법의 차이?

지난 주에 면접을 보고 왔는데 이런 질문을 받았습니다... Q) redux는 하나의 store를 가지고 recoil은 여러 개의 atom을 가지는데 여러 개의 저장소를 가지는 것과 하나의 저장소를 가지는 것에 대한 장단점이 어떤 것이 있을까요? 각 저장소 별로 역할을 구분할 수 있는 장점이 있다고 말씀드리긴 했는데 좋은 답변은 아니었던 것 같아요ㅠㅠ 위 질문에 대해 어떻게 답변드리면 좋은 답변이었을까요?

답변

안녕하세요:) Q) redux는 하나의 store를 가지고 recoil은 여러 개의 atom을 가지는데 여러 개의 저장소를 가지는 것과 하나의 저장소를 가지는 것에 대한 장단점이 어떤 것이 있을까요? 위의 질문에 대한 정확한 답변은 아니지만 Redux와 Recoil의 전반적인 장단점을 적어봤습니다! (작성자님이 React를 사용한다고 가정하고 답변했습니다.) Redux 장점: - 단일 스토어를 사용하고 있기 때문에 디버깅에 용이. Redux devtools와 같은 유명한 디버깅 툴이 있음. - 다양한 레퍼런스 단점 - 단일 스토어는 하나의 javascript 객체이기 때문에 상태가 변경될 때마다 많은 컴포넌트가 다시 렌더링됨. - 스토어, 액션, 리듀서 등 하나의 상태를 전역으로 관리하기 위해 많은 코드가 필요함. (redux toolkit을 사용하면 코드량을 줄일 수 있음) - Redux는 React 라이브러리가 아니기 때문에 React의 내부 스케줄러에 접근할 수 없음. 동시성 모드 지원이 어려울 수 있다. 참고) https://ui.toast.com/weekly-pick/ko_20200616 Recoil 장점: - 인터페이스가 간단. useState 사용하듯이 코드를 작성하면 됨. - React에서 유지 보수하는 라이브러리 React와 호환이 좋음. 단점: - 낮은 버전 (Redux보다 안정적이지 않을 수 있음), Redux에 비해 적은 레퍼런스 결론: - 리코일을 사용할 때의 큰 장점은 비동기 작업 처리, 상태 관리를 위한 간단한 인터페이스 인 것 같습니다. - 리덕스는 다양한 레퍼런스와 안정성으로 큰 규모의 프로젝트에 적합하다고 여겨져 왔는데요, 토스 등 몇 기업에서 상태관리로 recoil을 사용하는 것으로 봤을 때 리코일도 개발자 경험과 사용자 경험을 고려한 충분히 좋은 선택이 될 수 있을 것 같습니다. ref: https://ui.toast.com/weekly-pick/ko_20200616 https://www.imaginarycloud.com/blog/recoil-vs-redux/

2. 리액트에서 상태관리로 Redux를 무조건 공부해야할까요?

안녕하세요 저는 풀스택 개발자이고 2년만에 다시 리액트를 공부하려고 합니다. 얼마전에 리액트 2023 로드맵을 봤는데요 (사진 첨부했습니다.) 해당 로드맵에서 언급된 상태관리중 어떤걸 공부해야할지 고민됩니다. 상태관리 - 추천: Recoil, Zustand, Context - 대안: Redux / Toolkit, Mobx 2년전에는 Redux는 상태관리에서 거의 필수라고 했던 것 같은데 로드맵에서는 Recoil, Zustand, Context를 추천하고 Redux는 대안이라고 언급하네요. 요즘 리액트를 공부하게되면 Redux는 굳이 공부할 필요 없을까요? Recoil을 공부해보려고 하는데 Redux도 같이 공부해야하는 고민됩니다. 긴글 읽어주셔서 감사합니다.

답변

무조건 공부해야하는건 없습니다만. 이미 만들어진 많은 서비스들이 redux를 사용하고 있다는 점에서 배울 필요가 있습니다. 또한 많은 상태관리툴이 redux의 영향을 받은만큼 기본개녑같은 느낌으로 학습하시는걸 추천드립니다. 또한 팀원끼리 대화할때는 주로 공통된 지식이 베이스가 되는 경우가 많은데 상태관리의 베이스 지식이 아무래도 리덕스가 되는 경우가 많아요. 실무에서 안쓴다면 redux에 대한 공식문서에 대한 정독하고 나서 recoil zustand 등을 학습하시면 좋을것같습니다. context는 리액트에 속한 것이라 당연히 리액트 공부할때 보시면 좋아요.

3. 리액트 쿼리는 앞으로 어떻게 될까요?

최근 많은 컨퍼런스와 기술블로그에서 redux와 saga를 리액트 쿼리로 전환한 경험을 공유하고 있는데요. redux와 saga의 불편함과 복잡함에 비하면 리액트 쿼리는 훨씬 사용이 간편하고 캐싱과 같은 편리한 기능 때문에 그러한 내용들에 공감이 많이 됩니다. 하지만 리액트와 nextjs의 최신 버전을 보면 서버 사이드에서 데이터를 가져오는 방향으로 컴포넌트가 발전하고 있고 데이터 호출에 대한 캐싱도 제공하고 있습니다. 앞으로 이러한 기능이 점점 안정화가 된다면 유저정보와 같은 사용자만의 데이터 외에는 클라이언트 사이드에서 데이터 호출은 많이 줄어들 것으로 보이고 이 마저도 새롭게 나오는 use() 훅을 사용해볼 수 있을 것 같아서요 분명 서버데이터에 대한 상태관리 도구로 redux와 saga의 대안이 필요한건 맞지만 지금 시점에서 리액트 쿼리를 도입하는게 맞을지 고민이 되기도 합니다. 다른 개발자 분들은 어떻게 생각하시는지 궁금합니다!

답변

안녕하세요! 개인적으로 react-query가 최근에 떠오른 이유는 같은 문제를 다르게 풀었기 때문이라고 생각해요. 기존에는 서버/UI 상태 관리를 전역 상태 관리 툴에서 같이했다면, react-query는 서버 상태만을 위한 스토어에 여러가지 기능을 추가해서 사용하는 방식이죠. 캐싱, 로딩, 에러 처리, 리패칭 등 귀찮은 일을 대신 해주고, 쓰기 쉬웠던게 react-query를 많이 사용하는 이유라고 생각됩니다. 질문자님이 생각하시는 것처럼 미래에 서버 컴포넌트가 안정적으로 운영되기 시작하면 react-query가 내세우는 서버 상태 관리의 많은 부분을 대체할 수 있지 않을까 생각되네요. 하지만, 기존 레거시를 react 18로 올려서 서버 컴포넌트를 사용하는 것은 쉽지 않을 것 같습니다. 서버 컴포넌트라는 개념이 없던 시절에 짠 코드 베이스를 변경하는 작업은 상당히 까다로울 것 같아요. 기존에 react를 설계하고 짜왔던 방식을 조금 다르게 접근해야되니 개발자들이 습득하는데 시간이 걸릴 것 같기도 하구요. 결국, 기존 레거시가 react 18을 느리게 도입할수록 레거시에서 쓰던 react-query도 계속 사용되지 않을까 싶습니다. 저도 궁금한 주제네요 ㅎㅎ 참고했던 글들 링크 첨부할게요 - https://tech.kakaopay.com/post/react-server-components/ - https://beta.nextjs.org/docs/rendering/server-and-client-components - https://www.plasmic.app/blog/how-react-server-components-work#the-high-level-picture - https://www.youtube.com/watch?v=TQQPAU21ZUw

4. React - 상태관리라이브러리 디자인패턴이나 전략

리엑트와 상태관리라이브러리를 사용했을 때 어떠한 전략이나 디자인패턴 그런 것을 이해하기 어렵더라구여..ㅠㅠ 추천해주실만한 공부 로드맵?이 있을까요? 아니면 실무에서 어떤 디자인패턴을 사용하시나요?

답변

이런 흐름으로 공부해보세요! 1. React에서 '상태'에 대한 이해 - state, 상태란 무엇인지 - 상태의 변경에 따라 어떤 변화가 일어나는지 2. 전역 상태관리가 필요한 이유 - props drilling - context-api, 그 외 상태관리 라이브러리 (redux, recoil...) 3. 전역 상태 관리 라이브러리 비교 4. 비교한 상태 관리 라이브러리 개인 프로젝트에 적용 그외: remote-data-fetching library (react-query, swr) 기능 및 공부 관련된 블로그 글이나 도움될만한 링크도 공유드립니다! 1, 2번 '상태'관련 https://www.stevy.dev/react-state-management-guide/ 3번 라이브러리 비교 https://ridicorp.com/story/how-to-use-redux-in-ridi/