[3/20] 10장 상태관리

[loopy-lim]

생각해볼만한 점

• 서버가 과연 상태일까?
• SSOT에 대해 어디까지 생각해야할까?
• useState vs useReducer
  • 다수의 하위 필들를 포함하고 있는 복잡한 상태 로직을 다룰 때
  • 다음 상태가 이전 상태에 의존적일 때
• 주로 사용하는 상태관리는 어느건가요? 어떤 장점 때문에 사용하시나요?

[2yunseong]

서버가 과연 상태일까?

윤성

• 저는 상태라고 생각합니다. 컴포넌트 안에 한해서
• 서버에서 받아오는 데이터는 변하는 값이에요 (대부분의 상황이)
• 그러기 때문에 컴포넌트 입장에서, 리액트 입장에서는 상태로 보아야 하고, 이를 관리해야 한다 생각합니다.

채승

• 상태를 화면을 보여주는 입장에서는 동의. 사용자의 데이터를 관리한다는 측면에서는 동의못함
• 그 이유는 단순히 데이터일 뿐이지 상태로서의 의미는 가질 수 없다. (채승님이 생각하는 상태는 유저나 브라우저가 제어하는 값이라고 생각)
• 좀 더 설명하자면 보여지는 데이터를 갱신한다는 느낌이지, 상태라고 볼 수 있는지는 모르겠다.

[2yunseong]

SSOT에 대해 어디까지 생각해야할까?

채승

• 서버가 주는 값도 서버에 있는 값이라 나에게 HTTP 요청 으로 준 값이기 때문에 이미 SSOT 위반이다. 물리적으로 깰 수 없는.. (HTTP is stupid)
• SSOT를 잘 사용하고 있는지 검증하는 것은 실제로 그 값이 동일한 지 검증하는 것이다.
• 그래서 백엔드에서 온 값도 검증해야 한다. 그러기 때문에 zod, yup 등의 라이브러리가 존재한다.

윤성

• 앞에서 서버 값까지 SSOT를 고려해본다는 건 신선했다. 그리고 사고의 확장이 생김
• 저는 지금까지 React의 상태로서의 SSOT만 고려했었음. -> 이거 부터 잘해보자

바다

• React의 상태로서의 SSOT만 고려했었음.
• 다만 서버를 상태(react query)로 보았을 때의 SSOT는 고려하지 않고 코드를 구현했었다.
• 일단 서버 상태를 SSOT를 준수하면서 익혀보겠습니다 !

[2yunseong]

useState vs useReducer

채승

• 원래는 useReducer는 복잡한 state를 한번에 관리하기 위해 사용하여야 겠다고 생각했지만, 그게 아니라 FLUX 패턴에도 맞게에도 사용한다면 문제가 없겠다 라고 생각이 변했다.

윤성

• 손이 가는대로 치다보면 어느샌가 State가 컴포넌트에 한가득...
• 요즘은 점차 useReducer를 사용하고 있는데 예전에는 또 안쓴이유가 보일러 플레이팅이 많다보니까 손이 안가기도 하고, 상태로 끝나면 간단한데, 굳이 reducer작성하고 set할때마다 dispatch호출해서 action 넘겨줄 거 생각하면 그냥 state로 하는게 좀 더 생산성이 높다고 생각했어요
• 유지보수 측면에서 보면 복잡해지고 많아지면 useReducer를 사용하는게 좋지 않을까.. 라는 생각입니다.

바다

• useReducer를 사용할 만큼 복잡한 상황이 별로 없었고 useState가 많아지면, useReducer를 사용하기 보다는 지금 있는 코드를 더 개선해야겠다고만 생각함.

[2yunseong]

주로 사용하는 상태관리 라이브러리는 어느건가요? 어떤 장점 때문에 사용하시나요?

채승

• zustand. 데이터를 클로저 형태로 저장하기 때문에, 리액트 뿐만 아니라 다른 곳에서 사용하기 너무 좋다. hook뿐만 아니라 일반 function에서도 데이터를 긁어올 수 있다.
• 훅 사용없이 getState로 바로 가져올 수 있다. (read-only 인 상태)
  • 데이터 변경도 일반함수에서 가능한데, 조심해야 한다.
  • 아무래도 리액트의 생명 주기에 반하는... 일이 일어날 수 있다.
    read-only가 상태인가?
• yes~!! dto 예시를 생각해보자.
• Context API와 useSyncExternalStore를 자주 써야겠다.

윤성

• 놀랍게도 안씁니다. react query 밖에 안씁니다
• 사실 별로 쓸 일이 없어요 진짜
• 저번 프로젝트도 안썼고 (저의 극구 반대로)
• 이번 프로젝트도 안쓰고 있습니다 (저 혼자 하니까)
• recoil 사용이유는 쉽습니다. 매우
• 모든 전역상태관리라이브러리에 있는 개념인 것 같지만, atom - selector 모델이 직관적이게 이해할 수 있다?! -> 쉽다는 느낌을 주었던 것 같아용
• 나중에 제가 또 공부를 하면 바뀔 거 같습니다 (채승님의 추천 redux, zustand)
  왜 추천하시죠?? (by 채승)
• MobX, redux는 한번씩을 써보면 한다. 그 이유는 너무 오랫동안 장기 집권을 했던 세력이였기 때문에 개발자들이 이러한 멘탈을 모델을 은연중에 빌트인 하고있다.
• Zustand는 redux를 엄청 쉽게 만들었다는 것에 의의가 있다고 생각한다.

바다

• Jotai. 실제로 전역상태가 많으면 한~두개인데 보일러플레이팅이 많은 건 쓰고 싶지 않았고, useState와 거의 유사해서 사용함
• 그 후에는 써보았으니까 관성으로 인해 사용을 했던 것 같다.
• 다음 프로젝트에는 학습 측면에서 다른 라이브러리를 사용해보고 싶다.