4주차 리뷰

[choisohyun]

한 줄 요약, 주요 내용 정리, 인상 깊은 구절, 종합 평가 등 다양하게 작성

[whewchews]

[생각]

• 이전에 서비스를 Vue에서 React로 마이그레이션 하면서 가장 어려웠던 점이 상태관리 멘탈모델을 바꾸는 부분이었다.
• React는 불변상태를 기반으로 작동하는데, Vue3는 주로 proxy와 모듈 상태를 기반으로 상태를 관리했고, 변경 가능한 갱신을 하는 코드를 자주 작성해왔기 때문이다.
• 기존의 서비스는 중첩된 깊은 객체를 빈번하게 업데이트 하는 로직이 많아, 중첩된 객체 값을 간편하게 변경가능하면 코드 작성이 쉬웠다. 앱이 커질수록 디버깅이 힘들어지는 단점이 있었지만, 업데이트 할 때 불변상태와 리렌더링을 신경쓰는 것보다는 나았다.
• 리액트로 갈때 처음에는 Jotai를 사용했는데, UI 위주의 컴포넌트 단위에서는 문제가 없었지만, 나중에는 결국 불변상태 지향 모델로 인해 개발이 지연되었다. 변경 가능한 상태를 사용가능한 Mobx로 변경해 개발했었다. (Jotai는 리액트와의 궁합도 좋고 DX가 좋았는데 atom들이 점점 증가하며, 협업을 할 때 어떤 atom이 어디에 있는지 어떤 역할을 하는지 헷갈려지기도 했었다. atom의 응집도와 결합도를 어떻게 관리해야 할지, 네이밍을 어떻게 할지 폴더 관리를 어떻게 할지 등 컨벤션을 정하면서 점차 정리가 되었다.)
• 당시에도 이 책을 필요한 부분 일부 살펴보았는데 라이브러리 사용법을 익히는데 그쳤고 더 깊이 이해하지는 못했었다. 전역 상태관리 라이브러리로 인한 시행착오를 겪고 이 책을 다시 보니 감회가 새롭다.

[요약]

[8장] 사용 사례 시나리오 2: Jotai

• 작은 상태 조각인 아톰을 모델로 삼음
• 전역상태를 저장하는 위치? 컴포넌트 상태를 사용함
• 전역상태를 작성하는 방법? 불변 상태 모델 기반(상태 객체를 수정할 수 없고 항상 새로 만들어야 함)
• 전역상태를 읽는 방법? 컨텍스트 및 구독패턴 기반
• 리렌더링 최적화 하는 방법? Atoms-in-Atom - 배열 구조로 리렌더링 최적화

Atom

• 아톰은 하나의 상태를 나타냄. 작은 상태 조각이며, 리렌더링을 감지하는 최소 단위임.
• 컨텍스트의 기본 스토어로 인해, 아톰을 사용할 때는 공급자가 필요하지 않음.
• 상향식 접근법(bottom-up): 작은 아톰을 만들고 이를 결합해 더 큰 아톰을 만듦. 컴포넌트에 사용될 아톰만 추가해서 리렌더링 최적화

Jotai가 아톰 값을 저장하는 방식 이해하기

• 원시아톰은 useState처럼 동작하도록 설계되었음.
• atom config가 직접 해당 값을 가지지 않고, 아톰 값을 저장하는 store가 따로 있음.
• store에는 key가 아톰 config 객체이고, value가 아톰값인 WeakMap 객체가 있음.
• useAtom을 사용하면 기본적으로 모듈 수준에서 정의된 기본 store를 사용함.
• 컴포넌트 레벨에서 store를 생성하려면, Provider라는 Jotai의 컴포넌트를 사용해 생성할 수 있음.
• 아톰 config는 값을 가지지 않는 정의일 뿐이므로 재사용할 수 있음.

배열 구조 추가하기: Atoms-in-Atom

• 배열 아톰은 아톰이 요소인 배열을 보관하는데 사용된다.
• 배열에 새로운 요소를 추가하려면 새로운 아톰을 생성해서 추가해야한다.
• 아톰 config는 문자열로 평가할 수 있으며 UID를 반환한다.
• 요소를 렌더링하는 컴포넌트는 각 컴포넌트에서 아톰 config를 사용한다. 이렇게 하면 요소의 값을 쉽게 변경할 수 있고 리렌더링을 자연스럽게 피할 수 있다.

[9장] 사용 사례 시나리오 3: Valtio

• 전역 상태를 작성하는 방법? 변경 가능한 갱신 모델(mutating update model)
• 전역 상태를 저장하는 위치? 주로 모듈 상태용으로 사용됨
• 리렌더링 최적화? Proxy를 활용해 자동으로 최적화 <- 리액트와의 통합을 위해 Proxy를 사용
• 상태 사용 추적(state usage tracking) 기반 자동 렌더링 최적화

Proxy를 활용한 변경 감지 및 불변 상태 생성하기

• setState를 사용해야 하는 이유? 상태를 불변으로 갱신하고 싶기 때문
• Proxy를 사용하면 객체 연산을 감지하기 위한 핸들러처럼 사용해 setState와 유사한 동작을 수행할 수 있음

Proxy를 활용한 리렌더링 최적화

• Valtio는 Proxy를 사용해 변경 가능한 객체에서 변경 불가능한 객체(스냅숏)를 생성함.
• Valtio의 proxy와 snapshot 함수는 중첩된 객체에 대해서도 작동하며 스냅숏 생성을 최적화 한다.(속성이 변경될 때만 새 스냅숏을 생성함)
• useSnapshot에서 반환하는 값의 변수명을 snap으로 설정하는 것이 Valtio의 컨벤션

이러한 접근방식의 장단점

• 언제 사용하고 언제 사용하지 말아야 할까?
• 상태 업데이트 멘탈모델 - 불변 갱신 / 변경 가능한 갱신
• JS는 변경 가능한 갱신 허용 but 리액트는 불변 상태 중심
• 방법) Valtio의 상태와 리액트의 상태를 명확히 분리하는 것

변경 가능한 갱신의 장단점

• 장점: JS 함수 사용 가능 + 중첩된 객체 값 변경 용이 + 렌더링 최적화가 자동이라 코드 줄일 수 있음
• 단점: 예측 가능성 떨어짐, 디버깅 어려움 : 렌더링 최적화를 내부적으로 처리하기 때문

[hamo-o]

Atoms-in-Atom
한마디로, 아톰 내부의 요소를 아톰으로 만드는 것이다.

type Todo = {
	title: string;
	done: boolean;
};

type TodoAtom = PrimitiveAtom<Todo>;
const todoAtomsAtom = atom<TodoAtom[]>([]);

무슨 장점이 있을까?

1. 아톰은 문자열로 평가될 때 UID를 반환한다. -> key를 id로 사용하지 않아도 된다.
2. 배열 요소(아톰) 중 하나가 갱신되더라도, todoAtomsAtom 은 변경되지 않는다. → 리렌더링을 줄일 수 있다.

토스트를 직접 구현했을 때, 컨텍스트 API와 Jotai 두 방식 모두 사용해 봤는데 큰 차이를 느끼지 못했었습니다. 이 패턴을 활용하여 id값을 생성하는 로직을 없애볼 수 있을 것 같고, 토스트 하나하나의 상태를 독립적으로 관리하여 Jotai의 장점을 살려볼 수 있을 것 같습니다.

---

의존성 추적
조건부 평가에서 작동한다.

(get) => get(a) ? get(b) : get(c)

→ a 값이 참이면 a 와 b 의존,
→ a 값이 거짓이면 a 와 c 의존

처음 알게 된 기능인데 상황에 따라 의존성이 달라져야 할 때 유용하게 쓰일 것 같습니다.

[RAINBOWJYP]

Jotai가 리렌더링을 방지하기 위해 작은 단위의 원자 Atom으로 나눠 관리한다는 것을 파악했다. Bottom-Up 방식에 대해 이해할 수 있었다. Zustand와 Jotai 중에 무엇을 쓸지 고민했을 때 Jotai는 Recoil과 유사한 방식이고 Atom이 많아지면 코드가 많아지는게 아쉬워서 용량이 작은 Zustand를 선택했었는데 리렌더링 최적화부분에선 Jotai가 나쁘지 않은 것 같다. 배열 구조를 다룰 때 쓰는 Atoms-in-Atom 패턴은 상태 관리 뿐만 아니라 단일 요소를 바꾸기 위해 배열 전체를 갱신하는 경우에 활용해봐도 좋을 것 같다.
Valito는 이번에 처음 봤는데 자바스크립트 함수를 사용하여 갱신이 가능하다는거였는데 원조에 접근한 방식이지만 React 갱신방법에 익숙해있다보니 아 이런게 있구나...하고 흐린눈으로 보게되었다.

[choisohyun]

Jotai

• 스토어가 아톰 구성 객체와 아톰 값으로 구성된 WeakMap 객체다.
• 아톰 구성 객체는 atom 함수로 생성된다.
• 리렌더링을 피하기 위해 파생아톰을 만들어야 한다. (bottom-up: 작은 아톰을 결합해 더 큰 아톰을 만든다.)

bottom-up 방식을 사용했을 때 아톰이 많아져서 발생하는 혼선이 있지는 않을지?

Valito

• 자동 렌더링 최적화로 상태 사용 추적이라는 기법을 기반으로 한다.
• proxy함수를 사용하면 snapshot을 사용해 불변 객체를 만들 수 있다.