프론트엔드 상태 관리에는 잘 풀기 어려운 네 가지 문제가 있음

• 상태의 공유 범위를 바꾸기 어려움
• 공유 상태의 수명을 표현하기 어려움
• 파생 상태를 효율적으로 공유하기 어려움
• 상태를 기능 단위로 응집시키기 어려움

이건 사실 코드에서 상태를 컴포넌트 트리의 어디에 위치하는지로 작성하기 때문에 생기는 문제임

코드에서 어떤 상태들을 같은 수명을 가지는 인스턴스로 묶어야 하는지로 바꾸면 여러 문제들이 해결됨

Bunja를 사용해서 이 문제를 해결할 수 있음

Bunja는 다른 상태관리 라이브러리들과 다르게, 상태의 인스턴스와 그 인스턴스의 수명을 관리하는 라이브러리임

앞서 언급한 네가지 문제는 아래와 같이 풀림

• 상태의 공유 범위가 바뀌면 상태를 표현하는 방법도 바뀌는 문제
• Bunja에서는 공유 범위와 무관하게
  useBunja

라는 통일된 방법으로 상태 인스턴스를 사용할 수 있음

• Bunja에서는 공유 범위와 무관하게
• 공유 상태에 자연스러운 수명이 없는 문제
• Bunja 인스턴스는 실제 사용처가 존재하는 동안 유지되고, 마지막 사용처가 사라지면 함께 정리되는 식으로 수명 문제를 해결함
• Bunja와 연관된 리소스가 있다면
  bunja.effect

의cleanup

을 통해 같이 수명을 관리할 수 있음

• Bunja와 연관된 리소스가 있다면

• Bunja 인스턴스는 실제 사용처가 존재하는 동안 유지되고, 마지막 사용처가 사라지면 함께 정리되는 식으로 수명 문제를 해결함

• 파생 상태의 유일성을 보장하기 어려운 문제

• Bunja에서는 파생 값을 Hook 호출의 결과가 아니라 Bunja 인스턴스 안에 존재하는 하나의 상태 노드로 만들어서 여러 컴포넌트가 같은 파생 상태를 공유할 수 있음

• 상태들을 기능 단위로 응집하기 어려운 문제

• Bunja 자체가 하나의 기능 인스턴스가 될 수 있고,
  bunja.use

로 기능끼리 의존하도록 만들 수 있기 때문에 기능 내부의 제약을 외부 인터페이스로 꺼낼 필요가 줄어듦

• Bunja 자체가 하나의 기능 인스턴스가 될 수 있고,

그러니까 Bunja는 다음과 같은 멘탈모델을 제안함

상태가 어느 컴포넌트에 위치하는지를 관리하는 대신, 상태 인스턴스의 고유성과 의존성, 수명을 관리한다.

아래와 같이 책임을 분리해서 개발하면 수많은 프론트엔드 상태관리 문제들이 깔끔하게 해결됨

React로 어떤 UI가 현재 존재하는지를 표현하고,

Bunja로 어떤 기능 인스턴스가 현재 살아 있어야 하는지를 표현하고,

Jotai 같은 상태 관리 도구로 그 인스턴스 안의 값들이 어떻게 변화하고 파생되는지를 표현함