기술 Stack 정리 - Hanhae99-final-3team/final_FE GitHub Wiki

1. 리액트 차트 라이브러리

  • react-chartjs-2 ->공식문서의 가독성이 좋지 않다. (Components 에서 그래프에 대한 예시 설명이 없고 api를 어떻게 사용하는지에 대한 설명 밖에 없음)
  • Recharts -> 차트를 가져와 사용할 때에 컴포넌트의 형태로 가져와 사용하는 것을 선호 -> 프로젝트 성격에 가장 잘 맞는다. (간단한 차트사용)
  • Nivo.rocks -> 다양한 커스텀 기능 제공 (프로젝트 성격과 맞지 않음) -> 코드가 리액트 Hook으로 제공되기 때문에 차트를 삽입하기 원하는 컴포넌트에서 Hook의 호출만으로 가볍게 사용할 수 있다.
  • chart.js -> 사용성이 높고 인기가 많은 라이브러리 이지만 js 언어 기반으로 구현되어 있기 때문에 리액트에 친화적이지 않은 라이브러리

2. 상태관리 라이브러리 비교 (redux,mobx,redux-toolkit,recoil,zustand,react-query)

1) 리덕스

  • 장점
  1. 상태를 전역 관리할 때 효과적이다. => store라는 이름의 전역 자바스크립트 변수를 통해 상태를 한 곳에서 관리
  2. 상태를 읽기 전용으로 취급
  3. 단방향으로 데이터가 흐른다. 디버깅에 매우 용이. => 내가 어떤 액션을 실행하였고, 어떻게 데이터가 흐르는 지 예측이 가능해 디버깅에 용이 기록이 남아서 이전 상태로도 돌아갈 수 있다.
  • 단점
  1. 보일러 플레이트가 많다.
  2. 불변성을 지켜주기 위해 매번 state 객체를 만들어야 한다.
  3. 리덕스는 상태를 읽기 전용으로 취급할 뿐, 실제로 읽기 전용으로 만들지 않는다. 따라서 실수로 직접 변경하지 않도록 항상 주의해야 한다. 이를 예방하기 위해 immutable.js라이브러리도 존재
  • 리덕스는 언제 사용하나?
    • 실시간 데이터 상태가 변화하거나, 다른 스토어에 있는 데이터에도 접근하는 경우

2) 리덕스 툴킷

  • 장점
    • 리덕스에 비해 보일러플레이트가 적다. => 리듀서, 액션타입, 액션생성함수, 초기상태를 편하게 하나의 함수로 선언이 가능하다. => slice
    • 불변성을 유지하기 위해서 리덕스처럼 immutable.js라이브러리를 사용하거나 번거로운 코드를 사용하지 않고, 원하는 값을 직접 변경하면 알아서 불변성이 유지되면서 상태가 업데이트 된다.

3) MobX

  • 리덕스와 달리 번잡한 보일러 플레이트 코드들을 데코레이터(애노테이션) 제공으로 깔끔하게 해결이 가능하다.

장점

  • 객체지향적이다.
  • 서버개발자들에게 친숙한 아키텍처 , Java Spring Framework와 유사한 아키텍처구조를 지향하고 있어서 서버개발자들에게 보다 친숙하고 낮은 러닝 커브를 제공하고 전역 상태 관리 라이브러리의 장점을 그대로 적용하는 것이 가능하다.
  • 캡슐화 state를 오직 메소드를 통하여 변경할 수 있도록 Private하게 관리 가능
  • 불변성 유지를 위한 노력이 불필요 , immutable.js 라이브러리를 사용할 필요가 없다.

단점

  • 레퍼런스가 너무 없다.
  • 디버깅 툴이 없다. , 리덕스 데브 툴은 상태와 액션을 추적하기 간편하고, time travel이 가능하므로 디버깅이 수월
  • 코드가 더러워지기 쉽다, => 리덕스는 보일러 플레이트는 많지만 덕스 패턴을 따르면서 체계적으로 관리가능, mobx는 시간이 지나면서 코드를 관리하기가 어려우므로 코드가 더러워지기 쉽다.

언제 사용하나?

  • 한 스토어에 저장되는 데이터가 명확하고, 드물게 다른 스토어에 있는 데이터에 접근하는 경우
  • 작은 프로젝트
  • 복잡한 상태관리가 요구되지 않는 경우

4) Recoil

  • 장점

    • redux,mobx와 달리 React 전용 , React에 최적화
    • redux처럼 다양한 구성(action,reducer 등)을 할 필요가 없다. 비동기 요청이 매우 심플하다.
    • 상태 정의가 증분 및 분산되므로 코드분할이 가능하다.
    • 역호환성 방식으로 전체 앱 상태를 유지하는 것은 쉬우므로, 유지된 상태는 애플리케이션 변경에도 살아남을 수 있다. (캐싱)
    • 비동기 처리를 깔끔하게 처리할 수 있다.
    • 선언적 프로그래밍 비동기처리를 위임받아 처리하는 컴포넌트를 JSX로 선언함으로써 모든 비동기 문제를 해결한다.

  • 단점

    • 안정성에 대한 걱정
    • 실험적인 API들 recoil의 api중에는 아직도 _UNSAFE surfix가 붙은것이 많다 하지만 빠른 속도로 UNSAFE 딱지가 떼지고 있다.
    • devtools의 부재 리덕스의 devtools 만큼 훌륭한 디버깅툴이 아직 없다.
    • 관련 오픈소스 생태계가 redux에 비해서 부족하더

5) zustand

  • 특정 라이브러리에 엮이지 않는다. (그래도 React와 함께 쓸 수 있는 API는 기본적으로 제공한다.)
  • 한 개의 중앙에 집중된 형식의 스토어 구조를 활용하면서, 상태를 정의하고 사용하는 방법이 단순하다.
  • Context API를 사용할 때와 달리 상태 변경 시 불필요한 리랜더링을 일으키지 않도록 제어하기 쉽다.
  • store 구현 방식 및 변경 방식이 간단해 보일러플레이트 코드가 매우 줄어든다.

6) react-query

  • 장점

    • 캐싱
    • get을 한 데이터에 대해 update를 하면 자동으로 get을 다시 수행한다.
    • 데이터가 오래 되었다고 판단되면 다시 get (invalidateQueries)
    • 동일 데이터 여러번 요청하면 한번만 요청한다. (옵션에 따라 중복 호출 허용 시간 조절 가능)
    • 비동기 과정을 선언적으로 관리할 수 있다.
    • react hook과 사용하는 구조가 비슷하다.

  • 단점

    • 리액트 시장을 리덕스가 지배하다보니 커뮤니티 규모가 크지 않다.
    • queryKey에 대한 best practice 등이 잘 정립되지 않았다.

  • 채팅 - sock.js, webstomp.js

  • 유효성검사 - react-hook-form

[기본 Form vs react-hook-form vs Formik](https://velog.io/@ggg5483/%EA%B8%B0%EB%B3%B8-Form-vs-react-hook-form-vs-Formik)

  • 소셜로그인 - KAKAO
  • 현재위치 - geoloacation API, kakao
  • 실시간 검색 - 디바운싱, 스로틀
  • 이미지 리사이즈 라이브러리, 다른 방법 찾아서 비교