posts/how-to-handle-errors-3

[utterances-bot]

에러 처리를 어떻게 하면 좋을까? - 3 | rinae's devlog

React + Hooks + MST(mobx-state-tree) 사용 시 데이터와 UI 결합 에 대한 고민 및 아이디어

https://rinae.dev/posts/how-to-handle-errors-3

[channprj]

좋은 글 고맙습니다

[cometkim]

혹시 기회되시면 Suspense도 미리 써보세요!

[skt-t1-byungi]

저는 개인적으로 1번도 좋다고 생각해요. 2번은 컴포넌트끼리 쉽게 공유가능해지지만 대신 verbose해지니깐요. 코멧님 말씀처럼 서스펜스 쓰면 좀더 코드가 컴팩트해 질것 같은데 아직 프로덕션용이 아니라서 그전까진 저는 간단한 훅(https://github.com/skt-t1-byungi/use-waiter) 만들어서 하고 있습니다.

[adhrinae]

@skt-t1-byungi 저는 1번도 verbose 해질 것 같다는 생각이 들긴 했어요. 좀 더 한쪽 방식으로 많이 코드를 작성하다보면 명확히 드러날 것 같은데, 지금은 이런저런 시도를 하면서 적당히 혼재되어 있는 상태네요. 여전히 명확한 답과 컨벤션을 정하지 못한 상태지만요. useWaiter 도 흥미롭게 잘 봤습니다.

제가 훅으로만 이런걸 처리해야 한다고 하면 진작에 react-async 를 썼을테지만, 리액트가 모든 상태와 비지니스 로직을 다루게 되는 모양새가 되는 것 같아 "이게 정말 맞는거야?" 라는 생가이 자꾸 들어서 '필요한 용도에 맞다면 충분히 좋은 라이브러리겠다' 정도로만 마음속에 담아둔 상태입니다.

[skt-t1-byungi]

음 그런 의문이시라면 서스펜스가 나와도 해결이 안되겠네요. 서스펜스도 결국 리액트 내에서 선언적으로 쓰이는 용도지 요청상태가 리액트와 분리되어 별도로 개발자에 의해 프로그래머틱하게 관리되는건 아니니깐요..

근데 리액트와 비즈니스로직의 분리를 추구하시는 이유가 컴포넌트의 재사용 때문이신가요 아니면 리액트에서 뷰 같은 전체 프레임워크 전환을 위해서이신가요? 결국 분리란 것은 그 둘 사이에서 유연성을 확보하기 위한 것일텐데, 정확히 미래의 무엇을 위한 분리냐에 따라서 수위를 결정할 수 있지 않을까요? 분리의 정도를 빡세게 가져가면 가질수록 유연성은 높아지겠지만 서로 비의존적인 코드를 만들기 위해서 코드도 길어지고 편리한 기능들도 정말 많이 포기해야할 수 있다고 생각하거든요.

[adhrinae]

@skt-t1-byungi
질문하신 내용이 중요한 부분을 잘 짚어주셔서 나누어서 제가 고민하던 내용과 함께 답변해보겠습니다.

리액트와 비즈니스로직의 분리를 추구하시는 이유가 컴포넌트의 재사용 때문이신가요 아니면 리액트에서 뷰 같은 전체 프레임워크 전환을 위해서이신가요?

프레임워크 전환을 노리는 것은 아니지만, 현재 개발하고 유지보수하고 있는 앱에서 제가 생각하는 좀 더 깔끔한 아키텍쳐에 가깝다고 생각했기 때문에 UI와 비지니스 로직의 분리 전략을 취하고 있었습니다. 리액트 외의 다른 UI 라이브러리나 프레임워크로 옮길 생각은 전혀 없고요. 만약에 근본 인프라 전환을 한다고 하면 create-react-app 기반인 현재 앱을 Next.js 로 마이그레이션 하는 정도겠습니다. 덤으로 컴포넌트의 재사용성도 조금 끌어올릴 수 있겠네요. 개별 컴포넌트는 그냥 스토어의 액션만 호출해주는 (리덕스 애플리케이션이라면 dispatch) 만 적절히 해주면 되는 상태가 되니까요.

결국 분리란 것은 그 둘 사이에서 유연성을 확보하기 위한 것일텐데, 정확히 미래의 무엇을 위한 분리냐에 따라서 수위를 결정할 수 있지 않을까요?

제가 미래의 무엇을 위하여 이렇게 설계하고 있느냐는 결국 "뭐가 될진 몰라도 변경사항에 효율적으로 대응하고 싶다" 가 되겠습니다. 체감상 UI 와 관련된 단순 상태나 흐름은 컴포넌트에서만 관리하고, 좀 더 복잡하게 데이터를 다루고 처리해야하는 로직은 상태 컨테이너에 두는게 편했습니다.

분리의 정도를 빡세게 가져가면 가질수록 유연성은 높아지겠지만 서로 비의존적인 코드를 만들기 위해서 코드도 길어지고 편리한 기능들도 정말 많이 포기해야할 수 있다고 생각하거든요.

맞는 말씀입니다. 이전에 GraphQL 에 대해 궁금해하다 위에도 댓글 남겨주신 혜성님이 알려주신 정보도 있었는데, 보면 볼수록 UI 와 데이터가 결합되는데 큰 거부감을 가질 필요도 없곘다는 생각이 들었습니다. 예를 들면 분리의 단위가 UI / 데이터가 아니라 개별 컴포넌트끼리 분리되고 결합될 수 있는 형태로 단위를 바꿔 생각하는게 될 수 있겠네요.

저도 Suspense 는 많이 기대하고 있습니다. MobX + mobx-state-tree(MST) 를 몇 년 써오면서 큰 불만은 없었지만 Suspense 지원은 좀 요원한 상태이고, 어차피 MobX + MST의 모든 기능을 다 끌어내어 효율적으로 사용하는 것도 아닌 만큼 어떻게 전체 설계를 개선할 수 있을까 근본적인 부분부터 계속 고민하고 있고요.(다른 상태 관리 기법 도입, 컴포넌트의 구분 단위 재정립 등) 화두를 던져주신 덕분에 좀 더 깊게 생각을 하게 되었습니다. 항상 좋은 코멘트 남겨주셔서 고맙습니다.