MobX 상태관리와 useState 상태관리

MobX 상태관리와 useState 상태관리

AccountBook List Page를 처음에 MobX를 이용하여 상태관리를 하였다. 후에 전역적으로 관리할 페이지가 1개 뿐이고, 컴포넌트의 개수와 깊이가 깊지 않아서 useState로 리팩토링하였다. 그러면서 느꼈던 차이점을 간단하게 정리하였다.

📌 [FE] MobX 활용하여 Account 목록 Context로 관리하기

• mobx를 사용하면서 먼저 주의해야 할 점은 useContext로 옵저버블 데이터를 받을 때 구조 분해 할당을 해서는 안된다는 것이다.

  구조분해할당을 하면 옵저버블에서 일반 객체로 변환되어 데이터 변화에 따른 렌더링이 일어나지 않게 되기 때문이다.

  참조

• MobX의 구조는 보통 Store, Context, Hook 으로 나뉘게 된다. MobX는 불변성을 지키지 않아도 되어서 사용하기 매우 편리하다고 느꼈다.

📌 [FE] useState를 활용하여 Account 목록 상태 관리하기

• useState의 객체를 수정할 때는 직접 수정하면 안된다. 대신 spread 문법을 사용하여 기존 객체를 복사하여 새로운 객체를 만들고, 이 새로운 객체에서 상태를 업데이트 해줘야 한다. 즉, 불변성을 지켜줘야만 리액트가 컴포넌트의 상태가 업데이트 됐음을 감지할 수 있고 필요한 부분만을 리렌더링 할 수 있다.

  function RandomList() {
    const [items, setItems] = useState([]);
  const addItem = () => {
      setItems([
        ...items,
        {
          id: items.length,
          value: Math.random() * 100
        }
      ]);
    };
  return (
      <>
        <button onClick={addItem}>Add a number</button>
        <ul>
          {items.map(item => (
            <li key={item.id}>{item.value}</li>
          ))}
        </ul>
      </>
    );
  }

이건 Redux도 똑같은 부분이었는데 MobX에 비하면 사용하기에 있어 불편함이 따르는 부분이다. 물론 immutable한 값을 사용하는 것은 장점이 있다.

• 수정이 불가능하면 side effect가 발생할 확률이 낮아진다. side effect가 없는 함수는 병렬 처리를 효율적으로 할 수 있다.
• 수정 불가능한 변수는 thread-safe하므로 동기화 문제에서 자유롭다. 두 개의 스레드가 동시에 같은 변수를 수정하려고 하는 경우를 생각해보면 이해하기 쉽다.