[%] 리액트 스토어(상태관리) 에 대한 고민.(MobX)

[익명(106.101)]

나는 당연히 페이지(라우터)단위로 상태관리가 이루어져야한다고 생각했는데

모벡스 문서 보니까 UI state랑 Domain store 나누는 걸 추천하네.

두 개로 나누기에는 너무 각각의 사이즈가 커지고

라우터단위로 쪼개면 거기서 굳이 UI랑 Domain을 분리할 필요는 없다고 생각하는데

무엇이 더 좋은 방법일까?

[익명(223.39)]

로컬 상태는 아예 안쓰는거임? Ui state가 스토어 state아닐텐데

[익명(106.101)]

로컬 상태가 UI state고 리액트 기본 state를 쓰는 게 아니라 MobX store인데 걍 공식문서에서 명칭을 그렇게 지칭함.

[익명(223.39)]

난 몹엑스 안써서 정확하진 않지만 리덕스 기준으로 봐도 모든 상태를 스토어에서 관리하진 않음 ui 상태의 경우 부모 자식 정도 될텐데 그걸 글로벌 state로 처리하기 보다는 props하는게 맞지 특정 컴포넌트 isAvail이나 color등의 상태를 store에서 관리할 필요는 없잖아 상식적인 내용아님?

[익명(106.101)]

https://mobx.js.org/defining-data-stores.html

[야딩조무사(cir6174)]

링크에서도 그러지말라는데? - dc App

[익명(223.39)]

몹엑스가 리액트 컨텍스트랑 비슷하네
https://ko.mobx.js.org/defining-data-stores.html
한국어로
번역된 내용으로 봐도 무난할듯 지역상태쓰다가 그게 글로벌로 되면 store에 박는거잖아 그걸 ui나 domain 단위로 나누고 root로 컴바인하는거고 글고 두개로 나누는게 이님 도메인 n이랑 ui n으로 나누네

[익명(106.101)]

그니까 페이지가 n개면 2n개의 스토어를 쓸지 n개의 스토어를 쓸지인데 굳이 2n개가 필요할까 하는 게 고민임.

[야딩조무사(cir6174)]

애초에 페이지 생명주기에 종속적인 데이터를 mobx 스토어에 담을 필요가 있냐는거임

[익명(223.39)]

쪼개야하면 쪼개는거고 안쪼개도 되면 안쪼개는거지 원래 flux패턴 자체가 하나의 스토어임 몹엑스 자체도 결국 루트 store를 만든다는건 store가 여러개로 나뉜다기 보다는 Root store의 내부 구조가 나뉘는거지 하나의 덩치가 커지면 쪼개면 되는거 아니냐 작으면 묶어서 쓰고

[익명(223.39)]

아 그리고 로컬 상태는 스토어에 안넣는게 맞음

[야딩조무사(cir6174)]

일단 코드좀 보여주셈 상황마다 다른거라 말로하면 끝이 안남

[익명(106.101)]

mobx가 useState보다 빠르다고 함.

[야딩조무사(cir6174)]

진짜 복잡하게 리듀서 + 미들웨어 + 컨텍스트 조합해야 하는 코드면 안티패턴이지만 편의를 위해서 mobx에 넣는게 맞을수도 있음

[야딩조무사(cir6174)]

state좀 쓴다고 대부분 유의미한 퍼포먼스 저하 안생김 거기서 병목생기는 일 거의 없음

[야딩조무사(cir6174)]

님이 쓰는 예시를 봐야할듯 - dc App

[야딩조무사(cir6174)]

여기서 뭘보면됨

[야딩조무사(cir6174)]

근데 프로젝트 규모가 엄청 작은데 이정도면 걍 꼴리는대로 짜도 됨;

[익명(106.101)]

src/main/react

[익명(106.101)]

best practice가 목표임.

[익명(223.39)]

리액트 파트 보고 왔는데 이런 글 이 아니라 리액트에 대해서 조금 많이 배워야할거 같다. 걍 다른 사람 코드좀 보면서 고민해봐라. 글고 class 안쓴다 리액트에선는

[야딩조무사(cir6174)]

이건 mobx를 쓸 상황이 전혀 아님 hover 이런건 빼박 UI고 데이터 바인딩 때문에 쓰는거면 굳이 mobx보단 swr, react-query가 낫지

[야딩조무사(cir6174)]

api 연동에 mobx 쓰는건 취향이라 완전 틀린건 아니겠다

[익명(106.101)]

호버는 dnd 스크립트 때문에 있는 거임.

[야딩조무사(cir6174)]

이건 다른얘긴데 그냥 아토믹 디자인부터 틀린 것 같은데

[익명(106.101)]

class는 향후에 className 말고 정식으로 지원한다는 얘기가 있어서 쓰는 중

[야딩조무사(cir6174)]

그냥 코드 전반적으로 관심사 분리가 좀 이상함

[익명(223.39)]

기본적인 jsx, 훅 사용법 등 기본적인게 하나도 안되어 있는데 폴더 구조나 import따위야 개인 취향이라 쳐도 일단 리액트부터 이해하고 상태관리에 신경써야하지 않을까 싶네.

[야딩조무사(cir6174)]

이건 그냥 페이지 디렉터리마다 나눠서 컴포넌트랑 로직 다 때려박는게 더 관리하기 편할텐데 왜 이렇게 한거임

[야딩조무사(cir6174)]

여기서 mobx 잘썻다고 할 수 있는건 세션관리말곤 애매한데

[익명(106.101)]

molecules랑 organisms를 observer를 쓰는 컴포넌트랑 그렇지 않은 컴포넌트로 나눌까 생각중 atoms랑 pages말고는 사실 잘 모르겠음.

[야딩조무사(cir6174)]

굳이 컴포넌트 설계가 mobx에 종속적인건 안좋아보이는데

[야딩조무사(cir6174)]

state만 최대한 분리하고 그걸 바인딩하는건 님 맘대로 페이지 단위로 해도 상관은 없음

[야딩조무사(cir6174)]

그니까 컴포넌트에서 mobx로 데이터 바인딩 하는거 자체가 실수고 그거 할거면 pages나 예전에 말하던 container 같은것에서 최소한으로 데이터 바인딩 하고 props로 컴포넌트에 전달하는식으로 일단 고친다음에

[야딩조무사(cir6174)]

페이지에서 mobx쓸때 기존 데이터를 key마다 따로 유지해주는 식으로 확장해서 바인딩하면 님이 말한거 전부 만족하면서도 코드는 훨씬 낫지

[익명(106.101)]

예를 들어 DocumentList에서 스토어에 있는 리스트를 직접 보고있는데 이걸 Main에서 바인드해서 props로 넘겨주라는 얘기임? 그렇게 했을 때 이점이 뭐임?

[야딩조무사(cir6174)]

맞음 정확히는 components/ 디렉터리에 있는 컴포넌트들의 상태를 Props에만 영향받도록 코드를 개선하는 작업을 하란거임 이건 나중에 코드가 바뀌었을때 한 번 데여보면 알음

[야딩조무사(cir6174)]

님 코드를 보면 Axios에서 데이터를 당긴다음에 별다른 처리 없이 컴포넌트에 바로 바인딩 해버리는데 저거 데이터 포멧 살짝만 달라지면 코드 수정이 필요함

[야딩조무사(cir6174)]

지금은 1:1이라 문제가 안되는데 이제 1:n이 되는 순간 데이터 포멧을 맞추겠다고 Store에서 결과를 이전과 같게 수정할텐데 그러면 애초에 데이터 포멧을 바꾼 이유가 있을거고 보통 그런건 1:n 의 n중 하나에서 필요한 데이터가 있어서 스키마를 수정한 케이스일텐데 그러면 이제 기존 데이터랑 다른 컴포넌트랑 매칭하던거에 예외가 생기니까 짜증나지

[야딩조무사(cir6174)]

그거 말고도 지금 상태는 문제가 많은데 일단 데이터 종속을 제거하고 나면 컴포넌트 큰것도 더 작은 요소들로 분리하기가 수월하고 여기저기서 나눠쓰기 편함

[야딩조무사(cir6174)]

애초에 스프링도 있는거 보니까 3티어 아키텍처같은 기본적인건 알고있는 것 같은데 비슷한걸 프론트에서도 지키라는거임

[익명(106.101)]

데이터가 abcd일 때 abc가 필요하면 그것을 따로 페이지에서 처리해서 컴포넌트에 넘기라는 얘기지? 데이터 형식이 abdfg로 바뀌어도 페이지에서 {a:a,b:b,c:g}이런 식으로만 바꾸면 끝나게 펑션을 직접 호출하는 건 상관없음?

[야딩조무사(cir6174)]

함수 호출은 무슨말 하는지 잘 모르겠고 나머진 다 맞음

[야딩조무사(cir6174)]

지금 mobx 쓰는건 스프링 컨트롤러에서 DAO 그대로 보내는거랑 다를바 없음

[야딩조무사(cir6174)]

아무튼 데이터 바인딩을 꼭 페이지에서 할 필요는 없는데 가능하면 한곳에서 몰아서 하는게 맞고(보통은 페이지 단위고 로그인 상태창 같은건 따로 빼서 데이터 바인딩 하고 여러 페이지에서 공유하기도 함) 컴포넌트는 Props에만 종속적으로 바꾸면됨

[야딩조무사(cir6174)]

라우트 단위로 상태관리가 필요하면 걍 props context로 하면 되는거잖음 - dc App