devlog,

Vuex 리펙토링

FreeVue FreeVue Follow Jul 04, 2019 · 3 mins read
Vuex 리펙토링
Share this

Vue를 이용하여 업무를 진행하면서 처음 받은 소스는 Vuex가 적용되지 않은 소스였습니다. 각각의 페이지가 데이터를 관리하고 페이지별 데이터 이동은 라우터를 활용하는 형태였습니다.

당연히 데이터를 받아 해당 페이지에만 적용을 하니 컴포넌트를 나누는 점에서 한계가 왔습니다. 결국 Vuex를 도입하여 상태관리를 활용하기로 했습니다.

처음 상태관리는 로그인정도로만 사용을 했습니다. 아직 페이지에서 활용하는 데이터들을 굳이 Vuex를 이용해 관리를 해야하는지 의문이 들어 제외했습니다.

그렇게 해당 프로젝트는 정리를 하게 되었습니다.

다음 프로젝트에서도 이전의 경험으로 Vuex를 팝업이나 사이트 설정, 로그인에만 사용을 했고 역시 각각의 데이터들은 제외했습니다.

그 결과 컴포넌트는 나누기가 어려웠고 폴더구조 또한 세분화되지 않아 관리가 점점 어려워졌습니다.

.src
├── .assets
├── .static
|   ├── default.css
|   └── common.css
├── .components
├── .views
|   ├── .Car
|   |   ├── Register.vue
|   |   └── List.vue
|   ├── .Product
|   |   ├── Register.vue
|   |   └── List.vue
|   ├── .Zone
|   |   ├── Register.vue
|   |   └── List.vue
|   ├── Home.vue
|   └── Login.vue
├── .store
|   ├── state.js
|   ├── mutations.js
|   ├── getters.js
|   ├── actions.js
|   └── index.js
├── API.js
├── App.vue
└── main.js

2019년 5월 Vuex를 적극적으로 도입하기 전 프로젝트의 일부 디렉터리 구조입니다. 프로젝트의 규모가 날마다 커지니 컴포넌트는 열어볼 엄두가 나지 않았고, Vuex에는 뭐가 있는데 API는 어디서 호출을 하는지 찾기도 어려웠습니다.

그래서 아래의 규칙을 정하여 리펙토링을 시작했습니다.

아래의 규칙은 개인의 기준으로 절대적인 기준이 될 수 없습니다.

기본규칙 작성법

  • 카멜케이스를 기본으로 한다.
  • 인스턴스의 data, Vuex의 state, props의 기본값은 받아오는 값과 타입을 같게 설정한다.
  • 최대한 인스턴스의 data는 Vuex의 state로 옮긴다.
  • 폴더별 기능을 명확하게 정한다.
  • 소스는 적게 기능은 명확하게 구분하여 관리포인트를 줄인다.

인스턴스 작성법

export default {
  name: '',
  components: {},
  props: {},
  data: () => ({}),
  computed: {},
  watch: {},
  methods: {},

  // 이 후 라이프 싸이클 순서
}

components 작성법

  • 첫번째 글자를 대문자로 작성한다.
  • 모든 컴포넌트들은 ‘@/components’에서 import한다.
  • 어떠한 Vuex이벤트나 API연동은 존재하면 안된다.

containers 작성법

  • 첫번째 글자를 대문자로 작성한다.
  • 모든 컴포넌트들은 ‘@/containers’에서 import한다.
  • Vuex의 데이터를 받아 components에 props해주는 역할을 가진다.

methods 작성법

  • DOM 이벤트는 on을 사용한다. ex) onClick(), onSubmit(), onScroll()
  • 내부 구동 함수는 _을 사용한다. ex) _AutoSet(), _MoveTop()
  • DOM 이벤트를 우선으로 작성한다.

Vuex 작성법

  • Store의 Constant파일을 활용하여 명령어를 구성한다.
  • mutations은 actions에서만 실행된다.
  • 모든 API는 actions에서 실행된다.
  • actions은 프로미스로 작성하기를 권장한다.
  • 에러 대응은 dispatch를 실행한 함수에서 대응한다. actions는 오직 에러가 나는 곳만 보여준다.

Vuex 구성법

  • 각각의 페이지, 기능으로 구분하여 modules화한다.
.src
├── .assets
├── .static
|   ├── default.css
|   └── common.css
├── .components
├── .containers
|   ├── .Car
|   ├── .Product
|   ├── .Zone
|   ├── Home.vue
|   └── Login.vue
├── .views
|   ├── .Car
|   |   ├── Register.vue
|   |   └── List.vue
|   ├── .Product
|   |   ├── Register.vue
|   |   └── List.vue
|   ├── .Zone
|   |   ├── Register.vue
|   |   └── List.vue
|   ├── Home.vue
|   └── Login.vue
├── .store
|   ├── Constant.js
|   ├── Auth.js
|   ├── System.js
|   ├── Car.js
|   ├── Product.js
|   ├── Zone.js
|   └── index.js
├── .API
|   ├── Config.js
|   ├── Auth.js
|   ├── Car.js
|   ├── Product.js
|   ├── Zone.js
|   └── index.js
├── App.vue
└── main.js

파일은 많아졌으나 각각의 파일들이 하는 일들이 명확해져 관리가 조금 더 쉬워졌습니다.

다음 포스팅에는 각각의 파일들의 소스를 소개하면서 상태관리를 어떻게 리펙토링했는지 소개하겠습니다.