클라이언트 상태 관리 라이브러리에 대한 선택

[choichangyeon]

저희 프로젝트에서 클라이언트의 상태 관리를 위한 라이브러리를 Zustand로 진행하고자 얘기를 했었지만
현재 해당 라이브러리의 특징과 기획에 대한 적합성 측면을 고려하지 않아서 반려된 사실이 있습니다!

그렇기 때문에 여러 상태 관리 라이브러리를 찾아보고 그 내용들을 정리하면서 문서로 남기면 좋을 것 같아서 해당 discussion을 열었습니다!

상태 관리 분석글
Zquery 라이브러리

위에 두 가지 참고자료가 제가 진행했었던 상태 관리 라이브러리에서 사용됐던 내용들입니다! (진짜 참고만 하세용...)
블로그 글에 Zotai나 Valtio에 대한 글들도 있으니 확인하시고 의견 공유해 주세요!!

[choichangyeon]

제 블로그 글을 다시 확인해보니, Ducks 패턴에 대한 설명이 부족해보여 해당 내용에 대해서 분석한 내용을 작성해봅니다!

Ducks 패턴이란?

Redux의 보일러플레이트 문제를 해결하기 위해 등장한 Ducks 패턴은, 액션 타입, 액션 생성자, 리듀서를 별도의 파일이나 폴더에 분리하지 않고 하나의 모듈처럼 한 파일 내에 통합하여 작성하는 디자인 패턴입니다.

Ducks 패턴 등장 배경

기존의 Redux 방식은 액션 타입, 액션 생성자, 리듀서 등 관련 코드를 각각의 파일로 분리해 작성해야 했습니다. 이로 인해 프로젝트의 구조가 복잡해지고, 유지보수 및 관리 측면에서 어려움이 있었습니다. 이러한 문제를 해결하기 위해, 모든 Redux 관련 코드를 하나의 모듈로 관리하는 Ducks 패턴이 제안되었습니다.

Ducks 패턴의 기본 규칙

Ducks 패턴을 올바르게 적용하기 위해서는 다음의 규칙을 따라야 합니다.

1. Reducer의 기본 내보내기
   모듈은 반드시 reducer 함수를 default로 export해야 합니다.
2. 액션 생성자 함수
   액션 생성자(action creators)는 함수 형태로 export되어야 합니다.
3. 액션 타입 명명 규칙
   액션 타입은 npm-module-or-app/reducer/ACTION_TYPE 형식을 따라야 합니다.
4. 액션 타입의 재사용
   외부 리듀서가 해당 액션 타입을 구독하거나 참조해야 하는 경우, 액션 타입을 UPPER_SNAKE_CASE로 export할 수 있습니다.

코드 예시

아래는 Ducks 패턴을 적용한 코드 예시입니다.

// 액션 타입 (Action Types)
const SET_COUNT      = 'my-app/counter/SET_COUNT';
const INCREASE_COUNT = 'my-app/counter/INCREASE_COUNT';
const DECREASE_COUNT = 'my-app/counter/DECREASE_COUNT';

// 리듀서 (Reducer)
export default function reducer(state = 0, action = {}) {
    switch (action.type) {
        case SET_COUNT:
            return action.count;
        case INCREASE_COUNT:
            return state + 1;
        case DECREASE_COUNT:
            return state - 1;
        default:
            return state;
    }
}

// 액션 생성자 (Action Creators)
export function setCount(count) {
    return { type: SET_COUNT, count };
}

export function increaseCounter() {
    return { type: INCREASE_COUNT };
}

export function decreaseCounter() {
    return { type: DECREASE_COUNT };
}

// Side Effects (예: redux-thunk 미들웨어 사용)
export function getCount() {
    return dispatch => get('/count').then(count => dispatch(setCount(count)));
}

Ducks 패턴의 장점

코드 통합성: 관련된 Redux 로직을 하나의 파일로 모아두어, 파일 간 분산으로 인한 복잡함을 줄일 수 있습니다.

구조 단순화: 별도의 액션, 리듀서 파일을 유지할 필요가 없어 프로젝트 구조가 단순해집니다.

유지보수 용이: 모든 관련 코드가 한 곳에 있어 수정 및 확장이 쉬워집니다.

이와 같이 Ducks 패턴을 적용하면 Redux 관련 보일러플레이트를 크게 줄일 수 있으며, 프로젝트 관리 및 유지보수 측면에서 많은 이점을 얻을 수 있습니다.

[ImJaeOne]

저희가 어떤 부분을 상태 관리로 가져가면 좋을 지 숙지하신 후에 조사하시면 더 편하실 것 같아 답글 남깁니다~!

1. 캐릭터 (외형 변화, 레벨, 경험치 등)
   서버 상태: 경험치와 레벨은 서버 상태로 관리하여, 데이터가 서버에 반영되도록 합니다.
   클라이언트 상태: 캐릭터 외형은 클라이언트에서만 관리하여 불필요한 서버 요청을 피하고, 실시간 반영을 통해 유저에게 즉각적인 UI를 제공합니다.

2. 입력 값 임시 저장 (이력서 작성 등)
   서버 상태: 이력서와 같은 중요한 데이터는 최종 제출 시 서버로 전송하여 저장합니다.
   클라이언트 상태: 사용자가 입력하는 중간 상태는 클라이언트에서 관리합니다. 이를 통해 불필요한 데이터 통신을 줄이고, 페이지 새로 고침이나 이동 시에도 데이터가 유지될 수 있도록 합니다.

3. 목표 달성 상태 (면접 준비 완료, 자소서 제출 완료 등)
   서버 상태: 목표 달성 여부와 같은 주요 상태는 서버 상태로 관리합니다.
   클라이언트 상태: 목표 진행 상태(면접 준비 중, 자소서 작성 중 등)는 클라이언트에서 관리하고, 실시간 UI 업데이트를 통해 유저에게 즉각적인 피드백을 제공합니다. 불필요한 서버 요청을 피할 수 있습니다.

4. 화상 면접 (면접 기록, 남은 시간 등)
   서버 상태: 화상 면접과 관련된 중요한 데이터(면접 기록 등)는 서버 상태로 관리합니다.
   클라이언트 상태: 화상 면접 타이머와 같은 실시간 데이터는 클라이언트에서만 관리합니다.

5. 사용자 인증 상태 (로그인 상태 등)
   서버 상태: 사용자 인증 상태는 서버 상태로 관리하여 세션 유지나 로그인 상태 확인을 서버에서 처리합니다.
   클라이언트 상태: 로그인한 후 사용자의 인증 정보를 클라이언트에서 세션 혹은 로컬 저장소에 임시로 저장하여, 이후 페이지가 리프레시되어도 로그인 상태를 유지할 수 있도록 합니다.

현재 저희 프로젝트 기획이 확정나지 않아 예시인 점 양해 부탁드립니다!

[ImJaeOne]

생각해보니 저희는 next-auth를 사용하여 세션 유지와, 인증 처리를 서버에서 처리해주기 때문에 사용자 인증 상태는 빠져도 될 것 같습니다!

[hye410]

제가 담당한 mobX에 대해 코멘트를 남기겠습니다.
결론부터 말하자면 우리 프로젝트에서는 mobX를 전역 상태 관리 라이브러리로 쓰지 않는 것이 좋다고 생각합니다.
왜냐하면

• mobX는 기본적으로 객체지향성이 강하며 class를 사용하는 것이 안정적인데,
• 함수형 컴포넌트를 사용하는 우리 프로젝트에서 store만 class로 사용하는 것은 코드의 통일성을 저하시킵니다.
• 또한 React 컴포넌트에서 사용하려면 추가적으로 'mobx-react'를 설치해야 하는데
• 이는 당장 별도의 추가 설치 없이도 React 환경에서 바로 사용할 수 있는 zustand와 비교했을 때 경쟁력이 떨어집니다.

아래는 좀 더 자세한 설명입니다.

---

mobX는 Redux와 달리 보일러플레이트 코드가 적고
데코레이터(@)를 활용하여 깔끔하게 사용할 수 있다는 장점이 있습니다.
하지만 mobX는 기본적으로 객체지향적 스타일을 채택하고 있습니다.
이런 mobX의 특성 상 store를 class 형태로 관리하는 것이 일반적입니다.

counter store를 예시로 들어보겠습니다.

class CounterStore {
  @observable 
   _count = 0;

 @action 
  increment() {
   this._count ++;
 }

 @action 
  decrement() {
   this._count --;
 }

}

export default new CounterStore();

@observable은 상태를 나타내고,
@action은 상태를 변화시키는 함수를 의미합니다.
위의 예시를 보면, Redux에 비해 MobX는 스토어를 보다 깔끔하게 정의할 수 있다는 점을 알 수 있습니다.

물론 class 대신 아래와 같이 객체와 함수를 사용해서 상태를 만들 수도 있습니다.

import { makeAutoObservable } from "mobx";

const counterStore = {
  count: 0,
  increase() {
    this.count += 1;
  },
  decrease() {
    this.count -= 1;
  },
};

makeAutoObservable(counterStore); // 상태를 MobX에서 추적 가능하게 설정

export default counterStore;

MobX에서 제공하는 makeAutoObservable을 사용하여 this를 자동으로 바인딩해 줄 수 있지만, 이는 객체 리터럴 방식으로 함수형 패러다임과는 여전히 거리가 있습니다.

또한 mobX를 React 컴포넌트에서 사용하려면
mobx-react를 추가로 설치해야 합니다.
이는 mobx-react에서 제공하는 observer와 Provider가 필요하기 때문입니다.

import { observer } from "mobx-react";
const Counter = observer(({ store }) => (
  <div>{store.count}</div>
));

import { Provider } from "mobx-react";
<Provider counterStore={counterStore}>
  <YourComponent />
</Provider>;

observer는 함수형 컴포넌트를 감싸서 MobX 상태 변화를 추적하고 리렌더링을 트리거합니다.
또한 Provider는 MobX 스토어를 React의 Context로 제공하여 여러 컴포넌트에서 동일한 스토어를 사용할 수 있게 해줍니다.

---

따라서 우리 프로젝트에는 함수형 패러다임에 더 적합한 Zustand와 같은 상태 관리 라이브러리를 사용하는 것이 코드 일관성과 개발 효율성 측면에서 더 나은 선택이라고 판단됩니다.

[참고자료]https://techblog.woowahan.com/2599/
[참고영상]https://www.youtube.com/watch?v=ahEiKO0kVdM&list=PLOSNUO27qFbtYC5oRwJVsNavcPEI5uoiJ&index=19

[ImJaeOne]

Jotai는 Atom 기반으로 상태를 관리합니다. 각 Atom은 독립적인 상태 단위로, 상태를 개별적으로 관리할 수 있습니다. 상태를 세밀하게 분리할 수 있어, 특정 상태만을 관리하는 것이 간편합니다.

장점: 상태를 세밀하게 분리하고, 읽기와 쓰기 권한을 세분화할 수 있습니다.

단점: 상태가 많아지면, 상태 간 의존 관계를 관리하기가 복잡해질 수 있습니다. 상태를 독립적으로 분리하는 만큼, 여러 Atom이 상호작용해야 할 때 상태 로직을 다시 구성해야 할 수 있습니다.

--> 장점과 단점은 말로만 들으면 헷갈리실 것 같아 정리해놓은 Notion 주소 함께 보내드립니다!
장점은 counter로 예시 들었으며 단점은 캐릭터의 레벨 계산으로 예를 들었습니다!

물론 Jotai에서도 여러 개의 상태를 하나로 묶어 관리를 할 수 있지만 독립적인 상태를 관리한다는 이점을 포기한다면 굳이 Jotai를 사용해야 하나? 라는 의문점이 듭니다.
따라서 기획 단계에서 저희가 관리해야 할 상태가 많다고 판단된다면 Jotai는 저희 프로젝트에 어울리지 않는 상태 관리 라이브러리라고 생각합니다!

[parkminjo]

기획을 조금 더 구체화 해봐야 알 것 같지만,
저희 프로젝트에서 상태 관리하는게 너무 복잡하지 않다면 Zustand(혹은 다른 라이브러리)를, 상태 관리가 복잡해진다면 Redux를 선택하는게 좋을 것 같다고 생각합니다.

✚
Redux는 비동기 액션을 처리하기 위해 middleware를 지원하는데, middleware을 사용하기 위해서는 추가 학습이 필요한 상태입니다.
그런데 Zustand는 store 내부에서 비동기 로직을 손쉽게 처리할 수 있습니다.

현재 서버 상태 관리 라이브러리는 React Query를 사용하기로 했습니다. 그런데 Redux로 가게 된다면 RTK Query도 존재하기 때문에, RTK Query에 대해 생각해봐야된다는 점도 있습니다. 하하

---

Redux에 대해 조사한 내용입니다.

Redux 언제 쓰면 좋을까?

• 최상위 컴포넌트가 모든 상태를 가지고 있을때
• 앱 상태가 자주 업데이트 될 때 (= 계속 바뀌는 상당한 양의 데이터가 있을 때)
• 해당 상태를 업데이트하는 로직이 복잡할 때
• 앱에 대규모 코드베이스가 있으며 많은 사람이 작업할 때

Redux의 핵심 원칙

• single source of truth

  애플리케이션의 모든 상태는 하나의 중앙 저장소(store)에 보관됨

  ⇒ 상태의 일관성을 유지하고, 애플리케이션의 전역 상태를 한 곳에서 관리할 수 있음

• state is read-only

  Redux 상태는 읽기 전용으로 직접 수정할 수 없음

  액션으로만 상태를 변경할 수 있음 ⇒ 상태 변경의 예측 가능성을 높이고 의도하지 않은 상태 변경을 막을 수 있음

• changes are made with Pure Functions

  Reducer라는 순수 함수로 상태를 변경함

  Reducer는 동일한 입력에 항상 동일한 출력을 반환하는 함수 ⇒ 상태 변경을 예측할 수 있고 안정적으로 만들어줌

장점

1. 예측 가능한 상태 관리

   애플리케이션의 모든 상태를 단일 store에서 관리함

   상태는 변경될 때마다 순수 함수인 Reducer로 갱신돼 예측 가능하게 유지됨

   ⇒ 디버깅과 상태 추적이 쉬움

2. 일관된 전역 상태 관리

   애플리케이션의 전역 상태를 일관된 방식으로 관리하기 때문에 큰 애플리케이션에서도 모든 컴포넌트가 동일한 상태를 참조하고 업데이트할 수 있음

   ⇒ 복잡한 상태를 안정적으로 관리할 수 있음

3. Middleware 지원

   middleware로 액션 처리 과정을 확장할 수 있음 ⇒ 비동기 액션을 쉽게 처리함

   ⇒ API 호출이나 복잡한 로직을 효율적으로 관리할 수 있음

4. 풍부한 커뮤니티와 생테계

   2015년에 출시된 이후 오랫동안 사용되어 커뮤니티와 생태계가 풍부함

   학습 자료와 확장 기능이 풍부해 개발 속도와 효율성을 높일 수 있음

단점

1. 보일러플레이트 코드

   Redux의 상태 관리는 특정 패턴으로 사용됨

   액션 생성자 → 액션 타입 → Reducer 등의 형식으로 작성하는 반복 코드가 많아짐

   코드가 복잡해지면 유지 보수가 힘들며, 간단한 상태 관리에는 적합하지 않음

2. 높은 러닝 커브

   Redux의 개념은 초심자에게 어려움

   특히 비동기 로직을 처리할 때는 middleware가 필요하기 때문에 추가 학습이 필요함

3. 성능 문제

   상태 트리가 커지거나 업데이트가 빈번하면 불필요한 리렌더링이 발생하여 성능에 문제가 생길 수 있음

   상태 업데이트로 애플리케이션이 복잡해지면 성능 최적화에 추가 코드 관리가 필요함

---

[참고자료]
Redux 시작하기
당신에게 Redux는 필요 없을지도 모릅니다
Redux의 탄생

[choichangyeon]

저희는 결과적으로 zustand를 통해 상태관리를 진행하기로 결정했습니다.
다른 라이브러리와의 비교를 통해 결정한 이유 말하자면

Redux의 경우

복잡하고 대형 프로젝트의 경우 Redux를 통해 관리하고, 그에 비해 좀 더 소규모의 프로젝트에 대한 프로젝트에선 zustand를 권장하는 내용들이 많이 있었습니다.
저희는 대규모 프로젝트와 아닌 프로젝트의 기준을 잡기 힘들었지만 관리하기 위한 상태들의 목록을 명확히 하고 접근성이 좋은 zustand로 결정했습니다.

jotai의 경우

jotai는 상태에 대한 파일 관리를 나눠서 진행하는 Atomic 관점에서 저희의 목표와는 차이가 있었습니다.
저희는 캐릭터 혹은 목표 등 여러 상태들을 묶어서 관리하고자 하는데 jotai는 이와 반대되는 방향성을 제시하고 있습니다.
물론 하나의 파일에서 관리하는 방법도 존재하지만, 그렇다면 Atomic 패턴의 의미가 무색해지기 때문에 zustand로 결정했습니다.