상태 관리 도구 Zustand vs Jotai vs Valtio 비교

Redux, MobX 후발 주자로 나온 상태 관리 라이브러리 세 종을 비교해 보았습니다. (Recoil은 Experimental 단계이므로 후보에서 제외하였습니다.) 1. Zustand Mobx, Redux와 비슷하게 전역 상태를 Top-down 접근 방식으로 관리합니다. 가령 블로그를 위한 스토어를 모델링한다고 가정하면 큰 틀(Blog)에서 시작해서 디테일(Posts, Post..)하게 모델을 만들어나갑니다. 이러한 방식은 직관적이고 Redux로 상태 관리를 해 본 사람이 많기 때문에 팀에 도입하기도 쉽다는 장점이 있습니다. 또다른 특징으로는 React 외부에서 스토어에 접근이 가능합니다. 이는 React 외 다른 자바스크립트 프레임워크에서도 사용이 가능함을 의미합니다. 덧붙여, 불변성 관리를 도와주는 immer 라이브러리와의 궁합이 좋은 것으로 알려져 있습니다. - Flux 패턴 - 큰 규모의 앱에 권장 - NPM Trend: 96만 (1위) - 용량: 1.1kb (1위) 2. Jotai Zustand와 완전히 반대로, Bottom-up 방식으로 상태를 관리합니다. 먼저 세분화된 상태(Atom, 원자)를 정의한 다음, 셀렉터에 결합하여 더 큰 상태를 만듭니다. - Atom 패턴 - 중~대 규모의 앱에 권장 - NPM Trend: 22만 (2위) - 용량: 4.7kb (3위) 3. Valtio 전역 상태를 "직접" 변경할 수 있도록 허용하는 특징을 갖고 있습니다. 따라서, 상태 변경이 다른 라이브러리에 비해서 심플합니다(setState 같은 함수 호출필요 없이, state.count++ 하면 바로 반영). - Proxy 패턴 - 소규모 앱에 권장 - NPM Trend: 5.6만 (3위) - 용량: 2.7kb (2위) [결론] Zustand는 대부분 앱에 적합하며 우리에게 친숙한 Top-down 방식으로, 여러개의 스토어를 도메인 단위로 쪼개서 쉽게 관리할 수 있습니다. 반면에 작은 상태들을 대량으로 읽거나 쓰는 작업이 필요한 성능 중심 앱의 경우 Bottom-up 방식의 Jotai가 적합해보입니다. Valtio는 개인 프로젝트에서 간단하게 상태 관리가 필요할 때 사용하면 좋을듯 합니다. 만약 규모가 있는 새 프로젝트를 설계한다면 서버 상태는 React Query로, 로컬 상태는 Zustand+immer로 관리하면 이상적일것 같네요. 마지막으로 레딧에서 한 유저가 남긴 글을 인용하면서 글 마치겠습니다. “Zustand, Jotai and Valtio are modern implementations of the three main state paradigms: flux, atoms and proxies. If you know which of these paradigms suits the project best you can’t go wrong. they don’t compete, they just allow you to pick the right tool for a certain task.”

다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2022년 12월 7일 오전 9:40

댓글 0

    함께 읽은 게시물

    대규모 트래픽의 기준, 어려우시죠? 요건 콕 찝어 말씀드릴 수 있겠네요. (물론 개인적인 기준이긴 합니다만)


    “최적화가 잘 되어 있다는 가정하에, 현존하는 최고 사양의 하드웨어를 갖춘 단일 서버 혹은 단순한 로드밸런서만으로 받을 수 있는 한계를 넘는 트래픽”


    ... 더 보기

    나머지 책들도 알려달라고 하셔서 적어봅니다.

    ... 더 보기
    profile picture

    골빈해커

    Chief Maker

    내가 꼽는 소프트웨어 개발자 필독서 Top 3 중 하나. AI가 구현(코딩)을 대신해주는 시대이기에 소프트웨어 개발자라면 더욱 필수적으로 읽어야 할 책이 아닐지. 하지만 10년 뒤에는 코딩이라는 행위가 정말로 로스트 테크놀로지 같은 느낌이 될 수도 있을 것 같아, 한 번 더 읽어보기로했다.


    FSD와 Clean Architecture의 만남: Clean F.S.D

    FSD(Feature-Sliced Design)와 Clean Architecture.
    두 가지는 출발점이 달라 보이지만,

    ... 더 보기

    오늘의 탐라는 git rebase로군요.


    작은 팀에서는 rebase없이 그냥 날것의 커밋을 공유하는게 좋다고 생각하고, 큰 팀에서는 로컬 커밋에서만 자잘한 커밋을 약간 정리하는 차원에서 rebase를 하는게 좋다고 생각합니다.

    조회 1,039


    알고리즘 왜 풀어야 함?

    ... 더 보기

    알고리즘은 왜 풀어야 하나요?

    velog.io

    알고리즘은 왜 풀어야 하나요?

    개발자를 선택한 이유

    저는 직업이 인생에서 가장 중요한 요소라고 생각합니다. 인생의 2/3 이상을 일에 투자해야 하기 때문입니다.

    ... 더 보기

    조회 68