전역 상태 관리 라이브러리 사용 경험에 대해 말씀해주세요.

[byhhh2]

* : 사용해봄

• 전역 상태를 사용하는 부분 (대표)
  • theme 관련
  • server data, data fetching을 처리하는 코드

Context API *

간단 정리

• context: 전역 상태가 저장되는 context
• provider: 전역 상태를 제공하는 provider
• consumer: 전역 상태를 받아 사용하는 consumer

• 주된 용도 : 다양한 레벨에 네스팅된 많은 컴포넌트에게 데이터를 전달하는 역할! (즉, prop drillling을 해결하는 역할)
• 컴포넌트 합성으로 대체할 수 있다.
• redux와 다르게 여러 저장소가 존재할 수 있다.
• context API는 상태 관리 도구인가?
  • 아니라는 입장
    • 단순 값을 전달하는 파이프와 같다.
    • 주요 목적은 prop drilling을 피하는 것이다.
    • context는 전달되는 값을 결정하는 역할을 하고, 일반적으로 실제 상태관리는 useState와 함께 발생한다.
    • context는 이미 존재하는 상태를 context tree 내부에 포함된 다른 컴포넌트들에게 공유하는 방식이다.

장점 & 단점

장점

• prop drilling을 해결할 수 있다.
• 컴포넌트 합성으로 상위 컴포넌트가 복잡해지고, 하위 컴포넌트들이 필요 이상 유연해졌을 때 사용할 수 있다.
• 컴포넌트 간 결합성을 낮출 수 있다. provider가 인터페이스의 역할을 하고, 만약 명세가 변경된다면 provider만 변경하면 된다.

단점

• 만약 useContext를 사용하는 컴포넌트라면 모두 re-render된다. (즉, 변경된 state를 가져오지 않아도 그냥 re-render된다.)
• 컴포넌트의 재사용성이 떨어진다. (context에 의존하게 된다. presentation component로 쓰고 싶은 컴포넌트가 있어도 context가 쓰였다면 context에 따라 쓰일 수 있는지 없는지가 달라진다.)
• provider hell 야기 (context를 추가할 때마다 provider로 매번 감싸주어야한다.) (만약 render를 줄이기 위해 state를 provider 여러개로 분리하게 되면 발생할 수 있다.)
  • context를 하나의 커다란 store처럼 사용하면 render가 많이 발생한다.

활용 방안

• theme과 같은 상태 변경이 잘 일어나지 않는 변수를 전역적으로 사용할 수 있도록 쓴다.
• 테스트 코드를 작성할 때 mocking을 할 수 있다.
• context를 사용하게 됐을 때는 관심사의 분리가 가장 중요하다. (성능 최적화가 이뤄지지 않았기 때문에)

Redux *

간단 정리

• store: 앱의 상태는 하나의 저장소(store)안의 객체 트리에 저장된다.
• action: 저장소(store)를 변경하기 위해서는 액션 객체(action)를 보내야 한다.
• reducers: 액션(action)이 저장소(store)를 어떻게 변경해야할지 명시하기 위해서는 리듀서(reducers)를 작성하면 된다.
• middleware: dispatch된 action이 reducer에 도달하기 전 중간 영역에서 기능을 확장할 수 있도록 돕는다.

🧃 React에서 react-redux 사용하기 *

• redux 자체는 react, vue, angular 등과 함께 사용할 수 있는 독립형 라이브러리이다.
• 일반적으로 어떤 프레임워크를 사용하든 직접 store와 상호작용하기보다는 redux를 UI 프레임워크와 함께 묶는다.
• 즉, react-redux는 react와 redux를 바인딩해주는 라이브러리이다.
• react-redux 없이 react에서 redux를 사용하려면 현재 스토어의 상태에서 필요한 데이터만 추출해 UI를 업데이트 해주어야 한다.
  • react-redux가 스토어 상호작용 로직을 처리하기 때문에 직접 코드를 작성할 필요가 없어진다. (react-redux의 hook를 사용해 component가 store와 상호작용할 수 있다.)
• react-redux가 지원하는 모듈
  • Provider, useDispatch, useSelector, connect 등

여기서 context API와 redux의 관계를 설명할 수 있다.

즉, context API는 react-redux와 좀 더 관계있다고 말할 수 있다.
context는 context tree에 포함된 컴포넌트들이 명시적으로 props를 전달하지 않고도, 어디서든 상태값에 접근할 수 있는 방법을 제공한다.

즉, UI와 state를 바인딩해주는게 context라고 볼 수 있다.
react-redux는 store와 component를 바인딩해주기 때문에 둘은 상당히 비슷한 맥락이다.
state를 관리하는 것은 redux이고, UI와 state를 바인딩하는 것은 react-redux라고 볼 수 있다.

(react-redux에서는 v7부터 사용하던 context API를 제거했다. (각 컴포넌트가 store를 직접 구독하는 방식으로 변경됨.) 이유는 context가 빈번한 업데이트에 최적화되지 않았고, 성능 문제가 있었기 때문) - 참고

🧃 redux-toolkit (RTK)

• redux의 보일러 플레이트가 많은 단점을 해결하기 위해 등장
• CRA와 같은 역할이라고 볼 수 있다.

• configureStore: 기본 middleware로 redux-thunk를 추가해주거나, redux devtools를 활성화해줍니다.
• createReducer: mutative한 코드를 작성해도 immutable 업데이트가 이뤄지도록 로직을 간단히 할 수 있다.! (immer 라이브러리 사용)
• createAction: type과 생성자 함수를 따로 분리하지 않아도 된다.
• createSlice: createReducer와 createAction을 작성하지 않아도 된다.

장점 & 단점

(언제 사용하면 좋을까요?)

• 계속 변경되는 많은 양의 데이터가 있다.
• 상태를 위한 단 하나의 근원이 필요하다.
• 최상위 컴포넌트가 모든 상태를 가지고 있는 것이 적절하지 않다.
• 업데이트 로직이 복잡할 때
• 거대한 코드 베이스를 여러 사람이 작업할 때
• 상태 변경 시각화가 필요할 때
• side effect, memoization, 데이터 직렬화 등 상태 관리를 위해 더 강력한 기능이 필요할 때 (미들웨어 사용, redux devtools) ⇒ 미들웨어 기능을 빌려 액션이 전달될 때 추가적인 로직이 필요할 때, devtools을 이용한 버그 디버깅이 필요할 때
• UI 레이어와 분리된 상태 관리 로직 작성이 필요할 때
• 상태를 예측 가능한 방식으로 업데이트 하기 위해 쓴다.

장점

• action이 reducer에 도달하기 전 중간 영역에서 middleware를 통해 중간 로직을 실행시킬 수 있다.
• context API를 사용한 로직에서 렌더링 최적화를 이뤄내려면 provider hell이 발생할 수 있다. 하지만 redux의 connect와 useSelector 함수에는 내부 최적화가 잘 이뤄져 있어서 상태가 바뀔 때만 컴포넌트가 re-render된다.
• 매번 context를 만들어야하는 번거로움이 없다.
• 컴포넌트와 별개로 상태관리를 진행할 수 있다. (컴포넌트는 어떻게 렌더링할 것인가의 문제이지, 비즈니스 로직 컨테이너가 아니다.)

단점

• 보일러 플레이트 코드가 많다.
  • 쉬운 기능에도 reducer, action, dispatch를 작성해야한다.
• 입문하기 어려운 러닝커브 (connect를 사용하던 시절이 정말 어려웠다.)
• reducer를 불변성을 지키면서 작성하기 어렵다. (코드 길이가 정말 길어진다.)

데이터 패칭과 상태 관리

SPA가 등장하면서 데이터가 FE, BE 두 곳에 존재하게 되었다.

• 서버에서 받아온 데이터를 전혀 상관없는 컴포넌트에서 가지고 있어야 할 때

  • 예시 | 장바구니 페이지가 존재하고, 상품 목록 페이지가 존재한다. (두 페이지는 관련이 없다.)
    장바구니 페이지에서는 현재 장바구니에 담겨 있는 상품 목록을 확인할 수 있다. 그런데 상품 목록 페이지에서도 장바구니에 담겨 있는 상품이라면 담겨 있다는 표시를 해주어야 한다.
  
  

그럼 장바구니 목록 데이터는 전역 상태 store에 저장되어야 할까? 혹은
각 페이지에 접근할 때마다 새로 데이터를 불러와야 할까?

API 응답을 전역 상태 store에 저장하는 경우

• redux같은 상태 관리 라이브러리의 store를 backend 상태에 대한 data cache로 사용하는 것이다.
  • 예시 | 장바구니 페이지와, 목록 페이지에서 각 페이지에 접근할 때마다, 장바구니 데이터를 GET 한다면 API 낭비가 있을 수 있다.
  • 예시 | 만약 목록 페이지에서 장바구니 데이터를 수정하고 (PUT 요청을 보내고, store 데이터를 수정한다.) 장바구니 페이지로 왔을 때 장바구니 데이터를 GET 하지 않아도 된다. (store 데이터를 이미 수정했기 때문에)

문제

• fetching 해온 데이터의 경우 시간이 지날수록 서버 데이터와 일관성이 깨지기 때문에 데이터를 최신으로 유지하기 위해 주기적으로 re-fetching 하면서 FE, BE 두 곳에 존재하는 상태를 동기화 하여 데이터 일관성을 보장해줘야 한다. (추가적인 많은 코드 작성이 필요하다.)
  • 예시 | 상품 목록 페이지는 변경이 될 가능성이 많다. (상품이 중간에 품절될수도 있음.) 만약 상품 목록이 store에 저장되어 있다면 주기적으로 store를 동기화시켜주어야 한다.

---

비동기 처리 로직 관련 middleware

redux-thunk 활용 (redux middleware)

• 비동기 로직 분리 (비동기 로직들을 컴포넌트에 두지 않고, 비동기 처리는 thunk가 한다. 즉 액션에 비동기 로직을 넣는다. )
• 객체가 아닌 함수를 dispatch 할 수 있다.
• thunk : dispatch를 품은 action
  • 액션을 원하는 시점에 reducer에게 던질 수 있다. (비동기 처리)

단점

• action에서 너무 많은 일을 한다. 보통 action creator는 type + payload인 객체를 생성해서 반환하는 역할만 하는데, thunk에서는 API 요청이나 비동기 처리까지 하게됨으로써 본래의 역할이 모호해진다.
• action 안에 dispatch를 둘 수 있으므로 하나의 action안에서 여러 action을 dispatch 할 수 있다. 이는 결과를 예측하기 어렵게 만든다.

redux-saga 활용 (redux middleware)

• redux-saga는 액션을 모니터링하고 있다가, 특정 액션이 발생하면 이에 따라 특정 작업을 하는 방식으로 사용된다. (까다로운 비동기 작업을 처리할 수 있다.) ⇒ 즉, action에 대한 리스너를 사용
• redux-saga에서는 generator를 활용해 action을 모니터링하고, generator 함수를 saga라고 부른다. (generator를 통해 action의 순수성 보장)
• redux의 dispatch는 무조건 동기적으로 이뤄지며, redux-saga의 put을 활용하면 비동기적으로 dispatch를 할 수 있다.
• 필요한 비동기 처리는 모두 saga에서 작성되고 수행된다. (즉, saga에서 비동기 처리 로직을 놓음으로써 action이 순수하게 유지된다.)

단점

• 다양한 상황에 쓸 수 있는 만큼 제공되는 기능도 많고 사용방법도 진입장벽이 크다. (generator의 개념을 이해하고 있어야 해서 러닝커브가 높다.)

문제

• redux의 데이터를 주기적으로 비동기적 fetching하기 위해 redux-saga와 같은 middleware를 사용하는 경우가 많이 있다. 일관성 문제를 해결하기 위해 데이터 패칭 관련 상태와 액션들을 모두 정의하게 되면서 안 그래도 복잡한 로직이 더 복잡해지고, redux에서 너무 많은 일을 하게 됐다.
  • 카카오 예시를 보면 하나의 API당 1~4개의 액션이 생성되고, ducks 구조와, saga 파일들로 인해 프로젝트 구성이 복잡해 졌다.
• 서버 데이터와 클라이언트 데이터 구분이 모호해진다. 서버의 응답을 store에 저장할 필요가 없는 상황에도 구조의 조화를 위해 action, reducer를 만들게 된다.
• 서버 데이터를 위한 로직이 과도하게 커지고, redux를 활용하기 위한 보일러 플레이트가 비대해진다.
• 과연 redux에게 fetching을 맡기는 것이 redux 본연의 역할에 맞는 것일까? (redux 본연의 역할은 state manager)

API 요청은 이제 react-query, SWR에게 맡기자.

• redux로 요청에 관련된 상태를 관리하려면 요청 시작, 성공, 실패에 대한 3가지 액션을 준비해야하고, 해당 액션을 처리하는 로직도 준비해주어야 한다. (action + reducer ,,,)
• 하지만 redux + middleware가 빛날때도 있다. (특정 조건이 있을 때 특정 로직을 실행해야 하는 경우)

react-query의 활용 *

• store에서 비동기 통신 분리
• 서버에서 가져온 데이터를 캐싱한다. 심지어 데이터가 stale 할때 는 refetching을 자동적으로 한다. 클라이언트에서 최신 데이터를 바라봐야하는 상황이 있는데, (근본적으로 화면을 보고 있을 때, 페이지가 전환될 때, 데이터를 요청할 때 등이 있다.) react-query의 기본 옵션을 사용하면 이를 간단하게 해결 가능하다. 이런 react-query의 컨셉들로 인해 사용자는 항상 fresh한 데이터를 바라볼 수 있다.
• 서버 데이터와 클라이언트 데이터를 분리할 수 있다. (redux는 클라이언트 측 전역 데이터 관리, react-query는 서버 데이터만 관리)
  • 클라이언트 전역 데이터 : 단계별로 진행하는 컨텐츠에서 단계별로 입력 받는 값 등
• success 혹은 error 상황을 공통적으로 핸들링할 수 있다. (물론 redux, redux-saga 활용하면 redux도 가능함) (QueryClient의 defaultOptions를 통해 핸들링 가능)

참고

• https://ko.redux.js.org/
• https://olaf-go.medium.com/context-api-vs-redux-e8a53df99b8
• https://velog.io/@cada/React-Redux-vs-Context-API
• https://ko.reactjs.org/docs/context.html
• https://dev.rase.blog/21-10-07-context-and-state-management/
• [https://medium.com/react-native-seoul/context-api-어떻게-사용해야-하는가-9ef90247713](https://medium.com/react-native-seoul/context-api-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94%EA%B0%80-9ef90247713)
• https://ridicorp.com/story/how-to-use-redux-in-ridi/
• http://blog.hwahae.co.kr/all/tech/tech-tech/6946/
• https://react.vlpt.us/redux/
• [https://kooku0.github.io/blog/data-fetching-library-어떻게-사용해야할까/](https://kooku0.github.io/blog/data-fetching-library-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C/)
• https://react.vlpt.us/redux-middleware/10-redux-saga.html
• https://kyounghwan01.github.io/blog/React/redux/redux-saga/
• https://doqtqu.tistory.com/335
• https://min9nim.vercel.app/2020-04-23-redux-saga/ (redux-thunk ⇒ redux-saga)
• https://tech.kakao.com/2022/06/13/react-query/
• https://tech.osci.kr/2022/07/13/react-query/
• https://techblog.woowahan.com/6339/

[al-bur]

상태 전문가 무비...!

[airman5573]

무비 레전드네요

[airman5573]

왜 프론트 개발자가 되고 싶나요?

[airman5573]

MVC 패턴에 대해 소개해 주세요

[JUDONGHYEOK]

mvc단점은 뭐라고 생각하시나요?

[JUDONGHYEOK]

이걸 어떻게 해결하려고 했는지

[JUDONGHYEOK]

flux패턴이란?

[JUDONGHYEOK]

단방향 데이터바인딩 방식이 왜 오류를 찾기 쉬운지?

[JUDONGHYEOK]

flux의 단점?

[JUDONGHYEOK]

그걸 해결하려고 한 경험

[JUDONGHYEOK]

프롭스 드릴링이란?

[JUDONGHYEOK]

문제라고 생각해서 해결하는지?

[JUDONGHYEOK]

어떤방식으로 해결하는지?

[JUDONGHYEOK]

합성컴포넌트 소개?

[airman5573]

합성 컴포넌트의 단점은?

[airman5573]

리액트 쿼리는 왜 사용하셨나요?

[airman5573]

어떤 기능들이 편리했나요?

[airman5573]

캐시는 왜 필요한건가요?

[airman5573]

리액트는 어떤 부분에서 VanilaJS 로 웹앱을 만드는것보다 이점이 있을까요?

[JUDONGHYEOK]

리액트를 사용하면서 어려웠던점

[JUDONGHYEOK]

리액트의 상태주기

[JUDONGHYEOK]

클래스형 컴포넌트와 함수형 컴포넌트의 차이

[airman5573]

왜 클래스형 컴포넌트가 사용되었는가?