새해 첫 개발 서적 [리액트 훅을 활용한 마이크로 상태 관리]

 

새해 첫 개발 서적을 읽었다.

작년 10월 생일날에 회사 후배가 생일 선물로 사준 책이긴 한데,

시간이 없다는 핑계로 읽지 못하다가 퇴사한 이후로 시간 짬이 나서 읽게 됐다.

 

리액트에서 가장 중요한 것 중 하나는 상태 관리이다.

상태는 랜더링과 관계가 있으며 상태를 어떻게 설계하느냐에 따라서 애플리케이션의 성능을 좌우하기 때문이다.

 

이 책은 상태를 관리하고 최적화 하는 방식에 대한 내용보다는 상태가 무엇인지, 로컬 상태와 전역 상태, 전역 상태를 다루기 위한 기술 및 라이브러리, 그리고 그 라이브러리들에 대한 간단한 비교를 해주고 있다.

 

지금껏 회사의 대규모 프로젝트에서 여러가지 상태 관리 라이브러리를 사용했었다.

2022년에는 Redux로 상태관리를 했고, 2023년에는 Recoil과 react-query를 사용해 상태를 다뤘다.

2024년에는 Redux를 사용하던 애플리케이션에서 Redux를 Zustand로 마이그레이션 하고 Zustand로 전역 상태를 다뤘다.

가장 최근에 진행했던 프로젝트에는 Jotai를 사용해 상태를 다뤘다.

 

여러가지 상태 관리 라이브러리를 사용하면서 느낀점은, 기술을 선택할 때 단순히 "사용해보고싶다", "유명하니깐" 라는 이유보다는 명확한 근거를 가지고 라이브러리를 선택해야 한다는 점이다.

예를 들면 애플리케이션의 규모, 프론트앤드 애플리케이션에서 사용자의 상태를 얼마나 많이 다루는지, 상태관리 라이브러리의 사이즈 번들 사이즈, 같은 팀 개발자의 러닝 커브 등이 고려될 수 있다.

 

이번 책에서 개인적으로 가장 인상이 깊었던 점은 전역 상태 관리 라이브러리를 리랜더링 최적화 측면에서 바라보고 있다는 점이다.

전역 상태 관리 라이브러리를 사용하는 이유를 단순히 데이터 관점에서만 바라보고 있지는 않았나라는 반성도 들게 됐다.

 

두 번째로 인상 깊었던 점은 Jotai 사용 패턴이다.

데이터를 배열로 다루는 것은 개발 중 종종 있는 일이다.

배열 데이터를 상태로 다룬다면 해당 데이터를 다루는데 있어서 상당히 복잡한 로직이 작성될 수 있다.

Jotai에서는 배열 데이터를 더 쉽게 다룰 수 있는 패턴이 있는데, Atoms in Atom 패턴이다.

atom을 만들 때 atom 배열을 담는 atom을 만들고, atom을 자식 컴포넌트에 props로 내려주어 자식 컴포넌트에서는 전달받은 atom을 useAtom을 사용해 각각의 atom으로 다루는 패턴이다.

이런 패턴을 사용하면 기존 배열 데이터에서 현재의 index에 위치한 데이터를 찾지 않아도 데이터를 다룰 수 있다.

위 패턴은 조금 더 공부해서 다른 포스팅으로 남겨봐야겠다.

 

마지막으로 인상 깊었던 점은 React-Traked이다.

최근 프로젝트를 진행하며 이 상태가 과연 전역 상태일까? 라는 고민을 했고, 전역 상태를 남발하고 싶지 않아서 Context API를 사용해 데이터를 지엽적으로 공유하고 사용했다.

React Context API는 상태를 관리하는 라이브러리가 아닌 상태를 추적하는 라이브러리다.

Context는 상태를 공유하기 위해 Provider을 만들고 state를 주입하여 자식 컴포넌트 트리에 상태를 공유한다.

이때 Context Value를 복잡한 객체로 다룰 경우,

A 자식 컴포넌트가 구독하지 않는 값이 B 자식 컴포넌트에서 변경된다면 A 컴포넌트에서도 리랜더링이 발생한다.

이는 최악의 경우 애플리케이션의 성능을 저하시키는 요인이 될 수 있다.

React-Traked는 상태 추적 라이브러리로써 선택자 패턴으로 내부에서 상태 사용을 추적하며 자동으로 리랜더링 최적화를 해준다.

 

새해 첫 개발 서적을 읽고 나서 아직 프론트엔드 영역에는 배우고 생각할 내용이 많다는 것을 다시 한번 느꼈다.

올해는 주니어 개발자에서 미들급 개발자로 성장해야 하는 한 해라고 생각한다.

위 책을 시작으로 클린 코드, 소프트웨어 아키텍처 책을 읽어보며 독서 회고를 남기도록 하겠다.