23.07.05(수)

하루 요약

1. 11시 ~ 22시 : 공유 오피스

오늘 한 일

1. Gloddy 개발
   1. EasterEgg 컴포넌트 구현
   2. Vercel - Github Action 이용한 자동 배포
   3. 리팩토링 1, 리팩토링 2
2. Next.js 번역 코멘트 반영
3. 추가 공부 (고민)
   1. 전역 상태 관리 라이브러리, 어떤 게 좋을까?
   2. Server 데이터 관리 라이브러리, 어떤 게 좋을까?
   3. React hook Form, 사용할까 말까?

오늘 배운 내용 요약

React의 단방향 데이터 흐름으로 인한 Props Drilling을 해결하기 위해 많은 전역 상태 관리 라이브러리가 등장하였다. React에서 기본적으로 제공하는 Context API는 부모 컴포넌트에서 변화가 일어나면, 하위의 모든 컴포넌트가 리렌더링이 일어난다는 치명적인 단점이 있다.

• 그 외의 Redux는 Flux 패턴, 즉 사용자가 입력한 Action이 발생하면 dispatch에 의해 state값이 바뀐다. 이 바뀐 state를 반영하여 view가 변화한다.
• Recoil은 useState처럼 사용이 매우 간편하다. state가 변하면 변화된 state를 사용한느 컴포넌트만 리렌더링이 일어나는 Atom구조이다.
• Zustand는 Redux와 비슷한 FLUX 패턴을 사용한다. Redux와 달리 보일러 플레이트 코드가 적고, Sub/Pub 모델이다.

전역 상태관리, 즉 동기 데이터만으로는 서버에서 받아오는 데이터, 즉 비동기 데이터를 관리할 수 없다. 그래서 React Query와 SWR같은 data fetch 라이브러리가 등장했다. Redux에도 Redux Thunk, Redux Saga와 같은 기능이 있지만 여러 단점이 있다. 이 부분에는 추가학습이 필요해보인다.

data fetching 라이브러리를 통해 간편한 코드로 인해 선언적으로 프로그래밍이 가능하고, 동일한 API요청이 여러 번 호출되면 한 번만 실행디는 등 비동기 데이터를 관리하기에 매우 편리하다.

추가로 학습할 것

1. Redux의 Redux Thunk, Redux Saga가 있음에도, 사용하지 않는 이유?
2. Zustand라이브러리가 정말 최선일까? Redux 코드가 그 정도로 복잡할까?

오늘의 생각

이전 같았으면 Recoil이 가장 사용하기 편하니까 Recoil쓰자 ~ Redux를 가장 많이 사용하니까 Redux쓰자~ 했을 나인데, 오늘은 이러한 전역 상태 관리 라이브러리에 대해 심도 있게 공부해보았다. 그러한 과정 속에서 내가 정말로 왜 전역 상태 관리 라이브러리를 사용해야 하는 지, 왜 등장을 하게 되었는 지 알게 되었다. 다른 라이브러리도 알게되고, 내가 사용했던 라이브러리의 장단점 또한 알게 되어 흥미로운 시간이었다.

앞으로도 하나의 라이브러리를 쓰더라도 '왜 그걸 써야하는 지' 깊게 고민하며 쓰도록 하자.