react-native 프로젝트 구조

어떠한 프레임에 갇히기 싫어 expo를 사용하지 않고 react-native cli를 통해 시작했기 때문에 구조를 잡기 위해 더 많은 고생을 했다.

mvvm 패턴

출처: https://velog.io/@k7120792/Model-View-ViewModel-Pattern

구조를 잡기위해 하나의 모델링이 필요했다. 알아보면서 해당 패턴이 가장 작업하기에 혹은 유지보수하기에 명확하다는 생각이 들어 이를 반영하기로 했다.

최근 트렌드라고 하기엔 그렇지만 리액트도 그러고 많은 부분이 view단에서 정말 view의 역할만 하도록한다. 이 이유는 재사용성을 강조하고, 유지보수가 강조되고 있기 때문이라 생각한다.

이에 나 또한 mvvm패턴을 제대로 반영하기 위해 노력 중이다.

위의 구조로 구성하였다.

 

하나하나 살펴보자.
1. component

View에 해당한다

우선, screen을 기반으로 해서 component directory로 가졌다.
1) 메인 페이지 2) 공통 컴포넌트 3) 언어 4) 로그인
이렇게 크게 나눴고 그 안으로 세부 구조를 가지게 했다.

2. container

옛날 구조 느낌은 들긴하지만, 내가 생각하기에 의미상 도입하는 것이 더 명확하다는 생각이 돼서 도입했다.
container는 component를 담는 역할을 한다. 세분화 되어 있는 하나 하나의 재료들을 하나의 그릇으로 담는 느낌으로 갔다.
component는 데이터에 대한 바인딩이 없고 오직 view역할만 하고 container 부분에서 데이터 바인딩 역할을 한다.
이에 따라 view와 data에 대한 명확한 구분을 지어졌다.
----> 수정- container를 별도로 두었을 때 과하다는 생각이 들었다. screen의 역할이 너무 적어졌고 container의 역할을 병합하는게 더 깔끔할거같다는 생각에 container를 따로두지 않기로 했다.

3. screen

스크린은 container와 같은 역할로 가져갔다. 다른 회사 혹은 다른 팀은 어떻게 가져가나는 잘 모르지만, 해당 화면에 대한 컴포넌트를 담고 있은 개념으로 생각하고 있다. 이에 해당 스크린에 대한 문제가 생겼을 때 더 빠르게 추적할 수 있고, 개념상 더 편하다고 생각했기 때문에 이를 이렇게 적용했다.

 

4. queries

queries는 react query를 담은 디렉토리이다. 

react query를 도입함으로써 레이어층이 더 명확해질 수 있었다. mvvm 패턴으로 구상해 본다면 모델로써의 역할을 한다고 본다.

server side에 대한 상태 관리 + 비즈니스 로직의 처리를 해당 레이어에서 진행을 시켰다.

추가적으로 api 디렉토리를 하나 더 두어서, server side에 요청 부분은 별도로 분리를 시켜주었다. 이유는 조금 더 깔끔한 구조를 가질 수 있다고 판단해서이다.

간단한 예시를 보자.

위의 예시는 단순 데이터 리턴해주는 코드이다. 위와 같이 해당 부분에서 데이터를 가져오고 이 부분에서 데이터에 대해 가공과 같은 비즈니스 로직을 해당 부분에 역할을 부여해준다.

5. Hooks,  Service

hooks 또는 service는 view model로써 역할을 했다. 뷰에서 일어나는 이벤트, 뷰에 대한 상태변화 알림 등에 대한 역할을 최대한 해당 부분에 부여를 하였다.

 

모든 부분에 대해 언급은 하지 않았지만, 프로젝트를 구성하는 데에 있어 최대한 mvvm 모델의 틀을 지키려고 했습니다. 혹은 조금 더 편리하겠다(?) 라고 생각드는 부분은 나만의 구조를 세워 수정하며 진행하였습니다.