[동현] State-Management

[D5ng]

고민한 것.

• 해당 아티클에서의 옵저버 패턴을 사용할 때 초깃값이 객체여야만 한다는 문제가 있었다. redux를 사용하는 예제에서는 초깃값에 객체가 아니여도 되기 때문에, 아티클에서 사용하는 옵저버 패턴을 사용하지 않았고, redux를 참고해 구현했다. (Zustand에서도 반드시 객체로 초깃값을 지정하진 않는다.)
• 상태 관리 라이브러리를 보면서 리액트에서는 어떤 방식으로 동작하는지 소스코드를 봐보니, 웬만하면 Provider를 사용해 구현한 것을 확인했다. (Redux, Tanstack Query), SWR과 Zustand는 Provider를 사용하지 않고 전역 상태를 관리하는데, useSyncExternalStore라는 외부 스토어를 구독할 수 있는 Hook 덕분이라는것을 알게되었다.
• Redux 처럼 구현할 때 dispatch의 action.type의 값이 문자열이 아니라면 예외처리를 통해 에러를 발생시켰다. 또한, subscribe에서도 함수가 아닐 때 에러를 발생시키도록 했다. (예외처리를 하지 않으면 타입 에러가 발생해도 런타임에서는 제대로 동작함)

배운 점.

• 옵저버 패턴에 대해 이해했고, 앞으로 어떻게 사용할지 감이 잡혔다. 옵저버 패턴을 사용하는 라이브러리들을 찾아보니 Redux, Tanstack Query, Zustand 등등 상태관리와 연관이 있는곳들은 대부분 사용한다는것을 발견했다. 해당 아티클에서 만드는 옵저버 패턴과 Redux의 옵저버 패턴을 깊게 공부할 수 있었다.
• 중앙 집중식 관리가 없었더라면 각 컴포넌트에 상태가 종속되어 많은 코드가 필요해 뚱뚱해진다는 단점과 상태를 부모에서 자식으로 전달해주어야하는 props drilling 문제가 있다. 상태를 전역에서 관리를 하고, 해당 상태를 공유할 수 있다면 컴포넌트에 종속되는 문제를 해결할 수 있고, props drilling 문제도 해결할 수 있다.
• Flux Pattern을 사용하면서, 단방향 데이터 흐름을 통해 상태 관리와 데이터 흐름을 명확히 정의하고, 이를 통해 복잡도를 줄이며 디버깅을 용이하게 할 수 있음을 체득했다.
• 타입스크립트를 사용하더라도 런타임 환경에서 예외처리 해야한다는 것을 느꼈다.

[Seoin02]

아티클을 토대로 이해하기 바빠서 의문을 가지거나 다른 자료를 찾을 생각을 못했는데, 동현님 PR과 코드리뷰 받고 반성합니다...! 코드 168줄인데도 이해하는데 시간이 걸리네요ㅜㅜ 고생많으셨어요

[Seoin02]

에러 처리 굿입니다!

[Seoin02]

타입스크립트는 컴파일 시 타입 에러를 발생시키고, 런타임에서의 타입 안전성을 보장하지 않기 때문에 예외 처리 등을 해야 한다는 걸 덕분에 배웠습니다!!

[Seoin02]

이건 어떤 용도인가요?

[Seoin02]

type이나 util은 파일을 분리했는데 왜 상수는 파일을 분리하지 않으신건가요??

[D5ng]

type, util 파일을 분리한 곳은 아마 redux를 만든 곳일거에요. 거기는 코드가 조금 많아서 분리하는게 좋다라는 생각이였고, 사용하는 reducer에서는 한 파일에 모두 다 넣었습니다! 사용하는 입장에서 규모가 크지않다면 한 파일로 작성하는게 좋겠다 라는 생각을 했어요!

[Seoin02]

action의 초기 값을 지정하는 건가요??