기술 스택 정리(리액트)

전역 상태 관리

redux

• 리덕스는 단방향 데이터 흐름 구조를 사용함

• 리덕스에서 state가 업데이트 될 시 발생하는 flow
• redux store에 action을 dispatch 함 (ex: dispatch({type: 'counter/increment'}))
• store는 이전 state와 현재 action에 따라 reducer 함수를 실행, 그리고 return value를 새로운 state로 저장
• store는 구독한 모든 UI를 대상으로 store가 update 되었음을 알림
• store로 부터의 data가 필요한 각각의 UI 컴포넌트들은 그들이 필요한 state가 변화했는지 확인
• 데이터가 변한 각각의 컴포넌트들은 새로운 데이터로 강제 re 렌더링 됨

recoil

• 주요 개념: Atoms
• Atoms? 각각의 state들, 기존의 리액트 트리가 2차원 이라면 recoil의 아이디어는 이를 확장하여 3차원으로 보는 방식임. (즉 Atoms가 state를 담고 있고 이 Atoms가 변경되면 그를 참조하고 있는 컴포넌트만 update 되는 방식)

• selector

• selector란? 상태를 기반으로 하는 파생 데이터를 계산하는 데 사용 됨. 즉 상태는 atoms에 저장되고 이를 통한 계산된 값이 필요한 경우 selectos에 명시된 함수를 통해 계산됨.

Redux vs Recoil

• 참고 블로그
• https://velog.io/@woals3000/Redux-vs-Recoil
• https://www.imaginarycloud.com/blog/recoil-vs-redux/#recoilvsredux

• 사용 편리성 ⇒ Recoil이 더 편함, 작성해야 하는 코드의 수도 적을 뿐만 아니라 사용하기 더 쉬움

• 비동기 처리 ⇒ Redux는 redux 미들웨어를 필요로 함.( redux thunk, redux saga… ) 하지만 recoil에는 내장 되어 있어 추가 설치가 필요 없음

• 즉 여러 모로 recoil이 react를 사용할시에는 이점이 많음
• 유저 loading 처리에서도 recoil이 편리함

비동기 처리

react-query

• 비동기 처리시 자동으로 데이터를 캐싱해줌. (엄청난 장점)

• 무한 스크롤 구현 가능

• react hook과 사용하는 구조 유사 (useQuerie등)

• 비동기 과정을 선언적으로 활용 가능

• 기존의 클라이언트 상태와 서버 상태를 전역 상태관리로 하나로 묶어서 사용하던 것을 분리 가능

• retry, error 처리, loading 상태 처리가 매우 간편함

• 자동으로 가비지 컬렉션 지원함

useSWR

• react-query와 개념은 유사

• hook, 캐싱등 react-query와 유사

• tmi ) next js 만든 회사에서 만든 라이브러리

react-query vs useSWR

• useSWR에는 global fetcher가 있어서 useSWR 훅을 쓸 때 마다 fetcher 함수를 정의하여 주지 않아도 됨

• 반면에 data를 prefetching 할 일이 생긴다면 react-query는 이 기능을 지원하므로 react-query가 더 유리

• graphQL을 활용한다면 useSWR이 더 좋음

• 전반적으로 성능면에서 useSWR이 react-query보다 좋음. 따라서 application의 규모가 크다면 useSWR을 선택하는게 이득일 수 있고, 규모가 크지 않다면 react-query도 좋은 선택

Routing(SPA를 위하여…)

react-router-dom vs Next js

• react-router-dom은 추가 적인 코드 작성이 필요함

• next js는 페이지 기반으로 렌더링 되기 때문에 routing에 추가적인 코드가 필요하지 않음
• 즉 pages 폴더 안에 파일 명이 라우팅 경로가 됨…