Vue.js 프로젝트 구조 추천

Vue.js 를 이용하여 프로젝트를 생성 후, 고민이 빠지게 되는 것 중 하나가 프로젝트 구조입니다.

Back-End 프로젝트의 경우 대부분 비슷한 구조를 갖고 개발을 시작하기 때문에 협업을 할 때 서로 이해하기가 좋지요.

가령 Service, Controller, Dao(Mapper), Dto(Model) 등으로 분류 후 하위에 구체적인 구현체를 생성합니다.

Vue.js 의 Convention 가이드에도 프로젝트 구조는 특별히 언급이 되어 있지 않습니다.

그래서 여러 사람들의 프로젝트의 그 간의 경험으로 개발 및 유지보수에 좋은 구조를 소개드립니다.

Vue.js 는 Router, Store, API 그리고 각 페이지를 정의한 Component 로 구분할 수 있습니다.

그리고 mixin, plugin, util 등으로 분류할 구현체들이 있을 것입니다.

저는 다음과 같이 프로젝트 구조를 갖기를 추천드립니다.

1. 리소스 (이미지, 폰트, 아이콘 등)의 경우 public 하위로 위치시킵니다.

리소스는 소스와 분리시키기 위한 목적도 있지만, 프로젝트 Release시 빌드된 파일과 public 하위를 일괄 배포시키기 위함도 있습니다.

2. api, store, router 를 분리합니다.

2.1. api 설계를 할 때, 페이지 혹은 기능에 따라 URI 를 분류하며 최종 URI가 나타나게 됩니다.

URI 경로에 맞게끔 api 하위에 추가적인 분류를 수행하는 것도 좋습니다.

2.2. store 에 정의한 데이터는 브라우저 Local Storage 에 저장되는 것인데, 영구적으로 보관하는 것과 Clear 처리되는 데이터로 분류할 수 있습니다. 따라서 global 과 pages 를 나누어 하위 구현체를 각각 정의하였습니다.

* 특히, 각 Page 마다 Store 가 있기 보다는 Page 에 Store 가 필요한 경우만 정의하는 것이 좋습니다.

2.3. router 는 하위에 바로 구현체를 정의해도 좋고, 너무 페이지가 많을 경우 추가적인 분류 후 구현체를 생성하는 것이 좋습니다.

3. *.VUE 를 정의 구현체는 components 와 views 로 나눕니다.

Router 와 맵핑 되는 *.VUE 구현체는 views 하위에 위치시킵니다.

그리고 모든 *.VUE 에 오픈되어 Import 대상이 되는 것들은 components 하위에 구현합니다.

이는 유지보수 시, 접근 및 검토 대상이 되는 *.VUE 파일을 취소화 하기 위함과 개발 진행 시 중복 구현을 피하기 위함입니다.

위에서 components 를 예로 보겠습니다.

common 은 Selector, Data Table, Text Field 등 공용 컴포넌트를 정의하였고..

layout 은 각 페이지의 공통으로 적용될 레이아웃 컴포넌트를 정의하였습니다. 크게 로그인 전/후로 볼 수 있습니다.

template 은 각 페이지가 공통적으로 갖는 페이지 형태를 정의합니다. 동적 리사이즈가 가능한 템플릿 혹은 세로 스크롤이 생겨야 할 템플릿 또는 편집 기능에 특성화된 템플릿 등으로 나눌 수 있겠습니다.

views 의 경우는 router와 매칭이 되는 컴포넌트나 매칭되는 페이지에서만 사용하는 컴포넌트를 정의하는 것이 좋습니다.

4. mixins 는 *.js 파일로 만들어진 공용 자바 스크립트입니다.

여러 개의 *.Vue 파일에 중복되게 정의되는 Script 코드를 mixins 를 이용하여 단일화 할 수 있지요.

mixins 를 사용하지 않는 프로젝트도 있을 수 있기 때문에 어딘가 하위에 숨기기 보다는 src 바로 하위에 정의 함으로써 mixins 의 존재 여부를 한눈에 파악할 수 있습니다.

5. plugins 도 분류를 하는 이유는 이 프로젝트에 커스터마이징된 플러그인의 존재 여부를 파악하기 위함입니다.

주로 i18n 같은 locale 처리 라던가.. vuetify 같은 화면 컴포넌트 프레임워크의 설정을 예로 들 수 있겠습니다.

6. utils 는 공통적으로 어디서든 사용 가능한 자바스크립트 구현체입니다.

위에서 정의한 것 외에 어디서든 import 대상이 되는 것을 떄려 넣을 수 있는 만능 컨테이너? 같은 존재가 되어 조심스럽게 사용해야 합니다. 너무 많은 utils 는 유지보수에 어려움이 될 수 있기 때문입니다.

주로 Date 관련된 것이나 숫자, 문자열 Format, 값의 변환 처리 등 어떤 프로젝트에서 있을 만한 것들을 넣고 이 외에는 각 components 나 mixin 에서 적절한 네이밍으로 처리하려 구현하는 것이 좋습니다.

댓글