search

QueenCards / ProjectAnalysis

플젝뿌셔
1 stars 0 forks source link

[13] 전역 상태 라이브러리 선택 이유를 알려주세요. useContext나 useState등으로 대체 가능하지 않나요? #15

Closed hyeyoonS closed 4 months ago

hyeyoonS commented 5 months ago

📎 질문

전역 상태 라이브러리 선택 이유를 알려주세요. useContext나 useState등으로 대체 가능하지 않나요?

MyPetLog

✏ 구술 답변 키워드

  1. 사용 라이브러리: jotai
  2. 해당 라이브러리를 선택한 이유
  3. jotai의 장점
  4. useContext와 useState로 대체할 수 없는 이유

✏ 서술 답변

Jotai는 React 애플리케이션에서 전역 상태 관리를 간단하고 직관적으로 할 수 있게 해주는 상태 관리 라이브러리입니다. Jotai를 선택한 이유와 useContext나 useState로 대체할 수 없는 이유를 설명드리겠습니다.

Jotai를 선택한 이유

처음에는 Recoil을 염두에 두고 학습을 진행했습니다. React를 만든 기업에서 만든 React를 위한 라이브러리이기에 React와 호환성이 좋고 유지보수도 편리할 것이라고 판단했기 때문입니다. 따라서 Recoil에 대한 자료를 찾아보며 학습을 진행했는데, 학습을 마치고 프로젝트에 적용을 할 무 Recoil에 메모리 누수 문제가 있다는 것을 알게 되었고, Recoil과 거의 유사한 방식인 Jotai를 사용하게 되었습니다.

Jatai의 장점

단순하고 직관적인 API: Jotai는 매우 간단한 API를 제공합니다. Atom을 정의하고, 이를 사용하여 상태를 읽고 쓸 수 있습니다. 코드가 간결하고 직관적이어서 학습 면에서 좋습니다. 컴포넌트별 상태 분리: Jotai는 각 Atom이 독립적으로 작동하여, 상태 변경 시 필요한 컴포넌트만 리렌더링됩니다. 이는 성능 최적화에 유리합니다. 비동기 상태 관리: Jotai는 비동기 상태 관리도 간편하게 처리할 수 있습니다. 비동기 데이터 페칭을 Atom 내부에서 처리할 수 있어, 비동기 로직을 쉽게 관리할 수 있습니다. 리코일과 유사한 접근 방식: Jotai는 리코일(Recoil)과 유사한 접근 방식을 취하면서도 더 가볍고 간단한 API를 제공합니다. 이를 통해 전역 상태 관리를 쉽게 구현할 수 있습니다. 작은 번들 크기: Jotai는 번들 크기가 작아 애플리케이션의 성능에 큰 영향을 미치지 않습니다.

useContext와 useState로 대체할 수 없는 이유

useContext와 useState를 사용하여 상태를 전역으로 공유하려면, 컨텍스트 프로바이더를 정의하고 이를 애플리케이션 트리에서 적절히 배치해야 합니다. 이는 복잡성을 증가시키고, 코드 관리가 어려워집니다.

컨텍스트의 값이 변경되면 해당 컨텍스트를 구독하는 모든 컴포넌트가 리렌더링됩니다. 이는 성능에 부정적인 영향을 미칠 수 있습니다. Jotai는 필요한 부분만 리렌더링하여 이러한 문제를 해결합니다.

useState와 useContext로 비동기 로직을 처리하려면, 상태 업데이트와 비동기 함수를 관리하는 추가적인 코드가 필요합니다. Jotai는 비동기 상태 관리를 내장하고 있어 이를 간단하게 처리할 수 있습니다.

또한 useState로는 2 depth 이상의 전역 상태를 관리 하기에 적절하지 않습니다. prop driling이라는 한계가 있기 때문입니다.

ListyWave

✏ 구술 답변 키워드

  1. 사용 라이브러리: zustand
  2. 선택한 라이브러리
  3. 해당 라이브러리를 선택한 이유-zustand의 장점
  4. Context API를 사용하지 않은 이유

✏ 서술 답변

ListyWave 팀 사용한 전역상태관리 라이브러리

Zustand를 선택한 이유

  1. zustand란?
    1. 독일어로 ‘상태’라는 뜻을 가진 라이브러리. Jotai를 만든 개발자가 만든 라이브러리
  2. zustand의 장점
    1. 러닝커브가 낮다: 핵심 로직의 코드 줄 수가 42줄 밖에 되지 않는다.
    2. 작은 번들 사이즈: 다른 전역 상태관리 라이브러리들에 비해 번들 사이즈가 작다. (recoil:23.5kb, zustand:1.2kb, redux: 1.4kb : 2024-05-13 기준)
    3. 프로바이더 필요 없음.
    4. 적은 보일러 플레이트: 보일러플레이트가 거의 없다.
    5. 상태변경 시 불필요한 컴포넌트 렌더링 최소화:
      • useStore 훅을 사용하면, 상태 업데이트가 UI 렌더링을 일으키지 않도록 설정 가능
    6. SSR과의 호환성: zustand는 SSR을 간단하게 지원하여 다른 라이브러리와 비교하여 설정이 덜 복잡하다.
    7. 커뮤니티와 상태계: 빠르게 성장하는 커뮤니티와 활발한 개발 환경을 자랑한다.
    8. 여러 미들웨어 지원:
      1. redux Devtools를 지원하는 devtools 미들웨어: • redux에 영감을 받아 만들어져 같은 중앙 집중형으로 스토어 내부에서 상태 관리
      2. persist 미들웨어: 로컬 스토리지, 세션스토리지 등 여러 스토리지와 연계된다.

Context API를 사용하지 않은 이유

  1. Context API란?
    1. 리액트 16.3 버전에서 소개된 기능으로 컴포넌트 트리 전체에 걸쳐 데이터를 공유할 수 있는 방법을 제공한다.
    2. 장점:
      • Props Drilling 문제를 해결하고, 전역 상태를 관리하는데 유용하다.
      • 사용하기 쉽고, 추가적인 라이브러리 없이 리액트 자체에서 제공되는 기능이다.
    3. 단점:
      • 단순한 전역 상태 관리에 적합하며 복잡한 상태 로직이나 미들웨어를 필요로 하는 경우에는 한계가 있다.
      • Context API는 Provider 하위의 모든 Consumer(자식 컴포넌트)들이 Provider 속성이 변경될 때마다 전부 다시 렌더링됩니다. 즉, 상태를 사용하지 않는 컴포넌트도 전부 같이 렌더링이 됩니다..
      • 복잡성이 증가할수록 성능 저하의 문제를 일으킬 수 있고, 대규모 애플리케이션에서는 관리해야 할 상태의 양이 많아진다.
      • Context API만으로는 상태 업데이트 로직을 중앙에서 관리하기 어렵다.
  2. Context API를 사용하지 않은 이유?
    1. 학습 목적: 최대한 다양한 전역상태관리 라이브러리를 사용하기 위함.
    2. 렌더링 최적화:
      • Context API는 Provider 하위의 모든 Consumer(자식 컴포넌트)들이 Provider 속성이 변경될 때마다 전부 다시 렌더링됩니다. 이는 성능 저하를 문제를 일으킬 수 있습니다. 리스티웨이브는 서비스의 확장성을 생각하여 Context API가 아닌 다른 전역상태관리 라이브러리를 사용함.
kanglocal commented 4 months ago

전역 상태관리 라이브러리를 사용한 이유

Jyophie commented 4 months ago

(사실 Jotai를 프로젝트에서 제대로 활용하지 못했으나, 일반적으로 Jotai를 사용하는 이유와 useContext, useState만으로 관리하는 것에 대비하여 장점을 정리하겠습니다)

전역 상태 라이브러리 Jotai를 사용한 이유

Jotai는 전역 상태 관리를 atom 기반으로 간편하게 관리하기 위한 라이브러리이다. useContext나 useState만으로 상태를 관리하는 것보다 아래와 같은 상대적 장점을 얻을 수 있다.

1. 간편하고 유연한 전역 상태 관리 매우 간단하게 전역 상태 관리가 가능하다. useState와 유사한 api를 제공하지만, atom 단위로 쉽게 정의하고 사용할 수 있어서 코드의 복잡성을 줄이고, 상태 관리를 보다 직관적으로 할 수 있다. atom 단위로 쪼개어 관리하기 때문에 각각의 상태를 독립적으로 관리할 수 있고, atom 간의 의존성도 쉽게 설정할 수 있다.

2. 재렌더링 최적화 useContext를 사용하면 Context의 값이 변경될 때 해당 Context를 사용하는 모든 컴포넌트가 재렌더링된다. 하지만 Jotai는 상태가 변경될 때 관련된 atom을 사용하는 컴포넌트만 재렌더링하기 때문에 불필요한 재렌더링을 줄여 성능을 향상시킬 수 있다.

3. Suspense 지원 Jotai는 리액트 Suspense를 기본적으로 지원한다. Suspense를 사용해 비동기 작업을 처리하는 것이 매우 간단하고, 비동기 상태 관리에 강력한 기능을 제공한다.

Eugene-A-01 commented 4 months ago

Q. 전역 상태 라이브러리로 zustand를 선택한 이유 1. 러닝커브와 코드 간결성 리스티웨이브는 6주안에 구현을 마쳐야했고 애자일하게 진행된 프로젝트. 공부와 개발을 병행하며 마감에 맞추기 위해 전역상태관리 라이브러리로 보일러플레이트 20줄정도를 이해하면 응용이 가능할 정도로 러닝커브가 낮은 zustand 선택. 보일러플레이트 양과 복잡도 부분에서 장점을 가진다.

2. 기술 트렌드와 커뮤니티와 생태계 고려 zustand는 대안인 mobx, recoil, jotai에 비해 빠르게 성장중이다. 앞으로의 전역관리의 중심이 될 라이브러리를 공부하고 경험하고싶었다.

image

Q. useContext나 useState등으로 대체 가능하지 않나요?

zustand는 두가지 부분에서 context API가 대체하기 어려운 장점을 가진다.

  1. 프로바이더가 없는 구조. 렌더링 트리를 단순화 시킬수 있다.
  2. 불필요한 렌더링 최소화. context API가 의존하는 모든 컴포넌트를 재렌더링하는 방식에 비해 zustand의 셀렉터 함수를 이용해 재렌더링을 쉽게 방지할 수 있다.
hyeyoonS commented 4 months ago

Context API의 사용 방식, useContext나 useState 를 사용하지 않은 이유 리액트 16.3부터 도입된 context api를 사용하면 네이티브 리액트만으로 전역 상태관리가 가능합니다. React.createContext 메서드를 통해 Context를 만들고 useState를 이용해서 를 최상위 컴포넌트(App)에서 감싸주면, 하위 컴포넌트는 에 저장된 값을 사용할 수 있습니다. 하지만 이 때 Povider는 모든 하위 컴포넌트를 감싸고 있으므로, props drilling은 피하더라도 결과적으로 관련된 모든 컴포넌트가 리렌더링이 되는 사태가 발생합니다. 이를 해결하기 위해 useContext 훅을 사용해서 관리할 값마다 Provider를 지정할 수 있지만, 컨텍스트를 추가할 때마다 프로바이더로 매번 감싸줘야 하기 때문에 Provider hell을 야기할 수 있습니다.

전역 상태 라이브러리 선택 이유 : Jotai 처음에는 Recoil을 염두에 두고 학습을 진행했습니다. React를 만든 기업에서 만든 React를 위한 라이브러리이기에 React와 호환성이 좋고 유지보수도 편리할 것이라고 판단했기 때문입니다. 따라서 Recoil에 대한 자료를 찾아보며 학습을 진행했는데, 학습을 마치고 프로젝트에 적용을 할 무 Recoil에 메모리 누수 문제가 있다는 것을 알게 되었고, Recoil과 거의 유사한 방식인 Jotai를 사용하게 되었습니다.

Jotai에 관한 설명 React의 state와 비슷하게 컴포넌트 트리 안에 상태들이 존재 하며 이들이 상향식(bottom-up)으로 수집 및 공유됩니다. 상태들은 atom이라고 불리는 객체에서 설정 하며, 값의 참조와 조작은 React.useState와 유사하게 [state, setState] 튜플로 수행합니다.

HaydenDevK commented 4 months ago