[Feat/#49] 온보딩 유저 생성 기능 연결

[mooyoung2309]

PR 요약

📌 변경 사항

✅ PR check list

Linked Issue

close #49

[greetings1012]

수고하셨습니다! 혹시 온보딩에서 성별, 생일, 닉네임별로 Store과 View를 따로따로 나눈 이유가 있을까요?

[mooyoung2309]

@greetings1012 페이지를 따로 구성해서 따로 있습니다!

[greetings1012]

@greetings1012 페이지를 따로 구성해서 따로 있습니다!
아 그러면 여러 View를 한 Store로 구성하는 방법은 조금 비효율적일까요?

[mooyoung2309]

@greetings1012
이부분은 여러 생각들이 있겠지만, 보통의 경우에는 저는 나누는 편이 좋다고 생각합니다. 우선 첫번째 원칙은 큰것보다 잘게 쪼개는 것이 낫다.
이런 뷰들은 간단해서 분리는 선택의 영역이라고 생각해요. 어떻게보면 불필요하게 많이 분리한게 아닐까라는 생각도 들어요. 특히 네비게이션 뷰 안에서 모든 것을 처리할 수도 있게 설계도 할수있어보입니다. 단점은 하나의 뷰가 길어지는 것 뿐에서 출발하는 이유들일것같아요.

여러 View를 하나의 Store로 구성하는 경우에는 목적이 조금 다를 수 있을 것 같아요. 공유가 필요한 State경우에는 하나의 State로 설계하는 이점이 있어요. 예를 들면, 화면이 전환되어도 타이머가 계속 동작 되는 경우에는 A 화면에 있는 타이머와 B 화면에 있는 타이머의 State를 공유하도록 설계할 수 있거나, 부모가 타이머 State를 들고 자식한테 내려주는 구조로 설계할 수 있을 것 같아요.

하지만, 위의 상황은 State는 같더라도 Action이 다를 수 있어서 같은 Store로 구성하기 애매한 예시였고, 그렇다면 하나의 Store로 묶을 수 있는 상황은 거의 목적이 비슷한 독립적인 화면에서 Store를 동일하게 가져갈 수 있을 것 같아요. 예를 들면, 프로필 화면의 경우 내가 내 프로필보는 화면 A와 내가 남의 프로필을 보는 화면 B는 화면은 조금 다른데 로직은 거의 같은 경우가 있을 수 있어요. 이런 경우에는 Store 안에 Type을 두어 My와 Other을 구분하여 사용해도 좋을 것 같아요.

그런데도 저는 이런 상황에서도 Store를 다르게 가져가도 이유가 있다면 좋다고 생각합니다. 예를 들면, 지금 현재 상황은 My 프로필과 Other 프로필이 거의 유사한 기능이 있겠지만, 나중에는 좀 다른 로직이 추가될 수 있는 상황이 나타난다면(My프로필에서는 조회만 하는데 Other 프로필에서는 팔로우 추가 기능이 나중에 추가될 예정) 미리 확장성을 고려해서 분리하는 것도 좋아보입니다. 하지만 화면은 거의 동일하니 오히려 View를 공통으로 가져가는 것도 좋아보여요.

명확한 이유가 있다면 Store를 분리해도 좋고, 하나의 Store로 구성해도 좋을 것 같아요. 이 경우에는 공통된 상황이 없어서 하나의 Store로 가져가는 이점이 적다는 판단이었습니다.

[greetings1012]

지금까지는 Store의 분리 목적이 단순히 "비슷한 View를 관리하기 편한 단위로 묶는다" 정도로 생각하고 있었는데, 답변을 듣고 다시 생각해보니 위와 같은 경우에 Store를 하나로 관리한다면 수많은 case와 입력값들을 한 곳에서 관리해야 하고, 추후 기능을 추가해야 할 때도 Store를 나누었을 때보다 훨씬 많은 조건들을 추가해야 할 것 같다는 생각이 드네요. 자세한 답변 정말 감사합니다!