search

our-library / library-web

library-web
0 stars 0 forks source link

React 상태관리 라이브러리 채택 #12

Open yangjinhwa opened 4 years ago

yangjinhwa commented 4 years ago

1. Redux

리덕스 한글번역 문서

2. MobX

React에서 MobX경험기 - 우아한형제들 기술블로그

3. Context API

리엑트 context 공식문서 리덕스 없이 상태 관리하기

redux와 contextAPI의 차이

오직 전역 상태 관리를 위한다면 Context API를 사용한다. 상태 관리 외에 여러 기능이 필요하다면 Redux 를 사용한다. high-frequency한 어플리케이션의 경우 Context API를 사용하면 성능상 이슈가 있을 수 있다.

4. Recoil

Recoil 공식문서 Redux vs Context API vs Recoil 사용법

지나생각

현재 프로젝트는 규모나 리스크가 작고, 어느정도 실험적인 프로젝트라고 생각합니다. 또한 릴리즈 예정일이 11월인 만큼 개발 완료까지 주어진 시간이 짧습니다. 때문에 여러 상태관리 라이브러리 후보들 중, Recoil이 러닝커브가 낮으면서도 가장 react와 궁합이 잘 맞는 상태관리 라이브러리라고 생각합니다. 단점이 있다면 아직 redux만큼 생태계가 깊고 다양하지 않으며, 정식버전 패치 전이라는 부분이 있습니다. 하지만 facebook에서 공식 상태관리 라이브러리화를 진행중인 이상 앞으로 react와 함께하는 상태관리 라이브러리로 많은 비중을 차지할 것이라고 예상됩니다.

HyunmoAhn commented 4 years ago

여러 상태관리 라이브러리 후보들 중, Recoil이 러닝커브가 낮으면서도 가장 react와 궁합이 잘 맞는 상태관리 라이브러리라고 생각합니다.

일단 제 생각을 말하면 Recoil은 선택지가 아니라고 생각합니다. 공식 릴리즈가 아니라는 점은 검증되지 않은 라이브러리이며, 사용자에게 릴리즈 되는 서비스에서 사용할만한 라이브러리가 아니라는 것입니다. 만약, Recoil에 치명적인 결함이 발견되어 facebook 개발팀에서 이 프로젝트를 deprecate시킨다면 Recoil을 걷어내는 작업이나, Recoil내부 로직을 저희가 책임져야합니다. 그리고 어떤 결함이 있을지 검증 중인 라이브러리이기때문에 불완전한 라이브러리를 굳이 사용할 이유는 없다고 생각합니다. 따라서 아직까지는 Recoil을 적용하기엔 위험부담이 있어서 좋은 선택지가 아니라고 생각합니다.

HyunmoAhn commented 4 years ago

일단 짚고 넘어가야하는 것이, Global 상태관리를 위해서 무조건 라이브러리를 사용하는 것은 아닙니다.

상태관리를 하는 이유에 대해서 생각해보면 다음과 같습니다.

그렇다면, 상태관리를 위한 라이브러리를 도입을 해야하는 이유는 다음과 같습니다.

즉, 모든 상황을 해결하려면 issue에 정리해주신 것 처럼 상태관리를 위한 라이브러리를 도입해서 global하게 데이터를 관리하는게 맞습니다. 하지만 이야기하신대로 상태관리 라이브러리 도입에 대한 러닝커브가 높아서 일정상 도입이 불가능하다면 고민을 해보아야합니다.

위에 말했듯이, global 상태관리를 위해서 무조건 library를 도입해야하는 건 아닙니다. global하게 상태 관리를 해야하는 데이터가 어떤 것들이 있는지 확인해보고, 그 데이터들이 하위 컴포넌트로 얼마나 전달이 되야아하는지 검토를 해보아야합니다.

즉, 4가지를 고민해봐야 합니다.

  1. global 상태 관리가 필요한가? 필요하지 않다면 지금처럼 개발
  2. global 상태 관리에 library 도입이 필요한가? 필요하지 않다면 root 컴포넌트에 state를 통해서 관리하고 child components에 데이터를 전달.
  3. global 상태 관리에 library 도입이 필요하다면, 어떤 것을 사용해야할까? 3번을 채택했을 때, 지금과 같은 라이브러리 선택 논의를 진행 (Redux, Mobx, Context, Recoil)
  4. library를 선택했다면 그 라이브러리를 소화하고 실전에 적용하는데 일정내에 소화가 가능할까? 소화가 불가능하면 1,2번 중 차선책을 선택.

위 4가지에 대해서 고민을 해보셨거나, 고민해보지 않으셨다면 고민해서 답변 부탁드립니다.

yangjinhwa commented 4 years ago

  1. 상태관리는 이미 여러번 말씀드린 것과 같이 필요하다고 느꼈습니다. Props의 drilling이 우려되는 데이터 부분은

    • 로딩
    • 서버에 따로 저장하지 않는 책에 대한 각종 설정 (책 대여기간, 최대 대여 갯수, 알림 설정 등) 등이 있습니다.

  2. 라이브러리의 사용을 최소화 하기 위해 react에 내장돤 context API를 알아보았지만 1에서 우려한것과 같은 데이터 형태에는 적합하지 않은 상태관리 였습니다. (예약 알림 등과 같은 상태관리가 필요한데 잦은 빈도의 업데이트에 성능이 좋지 못한 점)

  3. 말씀하신바와 같이 Recoil이 비교적 안정화되지 못한 라이브러리이기는 하지만 로직이 단순한 만큼 작은 규모의 프로젝트의 빨리 적용시키고 그만큼 추후 피치못할 문제가 생겼을때 제거하는것 또한 빠를것이라고 생각했습니다. 반면 redux나 mobx는 한 번 스펙으로 결정하면 이후 변동사항이 적을수밖에 없는 복잡도를 가졌다고 생각했습니다. Recoil을 굳이 제외해야한다면 커뮤니티 규모가 큰 redux가 적합하다고 생각합니다.

  4. 최종적으로 기획 및 일정을 검토해본 결과 현재에 redux를 도입하는것은 시간이 너무 지체될 것 같아, 지금처럼 진행하기로 했습니다. 첫 배포 이후에도 꾸준히 업데이트 한다는 가정 아래 배포 이후 리펙토링 과정에서 도입을 재고려하기로 했습니다.

HyunmoAhn commented 4 years ago

네, global 상태관리는 필요하고, library 도입은 일정상 무리라고 결정하셨네요.

그러면 library를 사용하지 않고 어떤식으로 global하게 상태관리를 하실건지 고민해보셨나요?

yangjinhwa commented 4 years ago

가장 상위 컴포넌트에서 데이터를 불러오고 props로 내려주는것 아닌가요!?

HyunmoAhn commented 4 years ago

네, 맞습니다. 디테일한 부분은 코드로 이야기하시면 될 것 같아요.

branch 나눠서 작업해서 올려주시면 확인해볼게요.