웹/모바일 모노레포 프로젝트 패키지 설계 및 라우팅

웹/모바일 페이지를 둘다 만들고 같은 서비스를 공유하는 상황이었고

본부 정책이 같은 앱이라면 모바일을 웹뷰로 만들자고 협의했고 모노레포로 하자는 결정이 있었다.

프로젝트 관리도 편하고, 백엔드는 대부분 같이가져가기 때문에 모노레포도 충분히 장점이 있는 상황이었다.

 

우리 앱도 이러다보니 패키지 구조를 어떻게 가져갈 것인가? 라우팅 자체를 어떻게 구현할 것인가 이슈가 있었다.

 

패키지 부터 나누기가 힘들었다. 두가지 정도로 나뉘었는데-

첫번째 안은 아래와 같다.

src 

     -- web   

                 -- component

                 -- container

     -- mobile

                  --component

                  -- container

     -- store

     -- repo

 

두번째 안은 아래와 같다.

src

     -- component   

                          -- common

                          -- web

                          -- mobile

     -- container 

                         -- common

                         -- web

                         -- mobile

     -- store

     -- repo

 

 

1안과 2안 공통적으로 web, mobile을 제외한 소스 하위는 백엔드와 관련이 있는 프론트 로직들로 정리하기로 했다.

component는 뷰에 관한 것들이고 container는 로직과 바인딩 되어 있다.

예를 들면 container/에서 useEffect로 dataFetch 하고 event handing function 을 정의한다.

component/는 presentationer componet 역할을 하도록 구현하였다.  

 

1안과 2안 둘중에 고민을 하다. 프로젝트 관리의 용이함과 빌드를 할때 패키지 의존성이 복잡할 것 같다는 생각에 1안으로 정하였다. 다른 프로젝트라는 개념으로 생각하기로 하여서, 공통된 로직이 있다고 하더라도 상위로 빼지 않고 각 web, mobile 컴포넌트 하위에서 복사해서 쓰는 방향으로 진행하기로 했다.

 

그런데 프로젝트 성격상 같은 모노레포의 웹/모바일이 같이 있으므로 라우팅 경로가 매우 비슷했다.

처음에는 아래 차이밖에 없어 src 하위에 RouteUtils를 만들고 

"m/경로"

"/경로"

보통 이렇게 웹, 모바일이 다르면 /이전을 prefix로 설정해서 만들었다. 처음엔 hook이 아닌 객체로 파일을 생성했기에

웹이냐 모바일이냐 판단은  window.location.href 인 브라우저 객체를 활용했다.

즉 RouteUtils는 파일은 내가 이동하려고 하는 테마가 무엇인가에 따라 switch로 분기를 쳐서 알맞은 경로로 history.push를 해주는 파일이다. 프론트 상에서 가독성도 좋아지고, url 관리도 편해질 것 같다는 생각에 만들었다.

 

 

하지만 나는 이 구조가 맘에 들지 않았다

src하위에 루트부터 web, mobile을 나누는 구조이기 때문에  아무리 현재 route규칙이 비슷하다고 해도 따로 가져가야한다고 생각했다. 또한 constant또한 웹/모바일이 미묘하게 다르기 때문에 나누어져 있었다.

constant는 프론트 로직에서 가독성있는 코드를 만들기 위해 만든 매핑 상수들을 정리해놓은 파일이다.

보통 뷰에서 보여줄 텍스트를 매핑하거나 ex)'APPR01':'결제' 로직 가독성을 위해 ex) APPROVAL: "APPRS02" 사용한다.

팀원중 일부는 route와 constant를 모두 src 하위로 가져가야 한다고 주장하는 사람도 있었다.

 

사실 어떤 방법을 선택하더라도 둘다 나름대로 타당한 이유가 있다고 생각했다.

하지만 국제화를 ux팀에서 진행하고, 본부 국제화 관리가 웹, 모바일이 나눠져서 관리하기 때문에 우리 프로젝트에서도 web, mobile 국제화 파일을 따로 관리할 수밖에 없었고, 그렇기에 constant또한 국제화와 마찬가지로 web, mobile 바위로 이동했다. route 역시 개념적으로 constant와 같은 레벨이라고 생각하기 때문에 web, mobile 하위에 만들기로 했다.

 

막상 보니 routeUtil에 history를 넘겨줘야하는게 눈에 거슬렸고, hook으로 만들기로 결정했다. 또한 utils라는 이름 자체가 디바이스에 상관없이 공용적으로 사용할 수 있는 공통로직이라고 생각해서 네이밍 컨벤션도 적절하지 않다고 생각했다. 물론 어떤 관점에 따라 보기에는 util이라는 이름도 적잘하다고 생각할 수 있다. 이건 취향 차이라고 생각했다.

 

그래서 결국 web/ mobile/ 하위에 공통으로 사용할 수 있는 커스텀 훅의 용도로 사용할 hooks 디렉토리를 만들고 RouteUtils를 useRoute로 변경하였다.