1년전에 개발했던 프로젝트가 추가개선이 된다고한다.
본격적인 개발을 하기앞서 기존코드의 리팩토링을 진행했다.
어떤 책에서 새로운 내용을 추가하는것보다 새로운 내용이 쉽게 추가되도록 기존내용을 수정하는것에 더 많은 시간이 투자된다고했었는데, 그게 무슨말인지 얼핏 알 것 같다.
일단 전체페이지에서 에러레이어를 띄우던 구조에서 영역별로 에러화면을 띄우는 기획안으로 변경이되었다.
이 사소한 기획안 변경이 프로젝트 구조의 근간을 고쳐야하는 상황이 되었다.
- 영역별로 스토어 모듈을 나누고, 각 모듈에서 에러상태를 기록하도록 수정했다.
- 각 에러레이어를 영역에 맞춰 띄워주기위해 영역을 감싸는 container component를 작성했다.
다음부터 프로젝트를 진행할땐 어느정도 확장성을 고려하고 개발을 진행해야겠다.
물론 이번기획은 전혀 예상못했던 내용이라,, 1년전에 확장성을 고려해서 개발했다고해도 대응할 수 없었을 것 같긴하다.. ㅠㅠ
[vuex] root mutation호출
namespaced 모듈에서 root 모듈의 actions이나 mutation을 호출해야하는 경우가 있다.
// root mutation
commit('globalMutation', payload, { root: true })
// namespaced mutation
commit('module1/mutation', payload, { root: true })https://stackoverflow.com/questions/44618440/vuex-how-to-commit-a-global-mutation-in-a-module-action
에러처리에 대한 고민
에러처리는 항상 어디서 어떻게 처리해야할지 고민이된다.
이번에 리펙토링을 진행하면서 다른 프로젝트들을 참고했다.
에러에 대한 전체팝업을 띄워주어야할 경우, root component에서 띄워주어야한다.
팝업 노출유무에 대한 상태값을 어디서 관리하느냐에따라 개발방식이 조금은 달라지는데, 상태값을 어떻게 접근하여 변경시키느냐가 차이점이다.
전역 store에 저장/관리
상태관리 라이브러리의 action(or mutation)을 이용한다.
vuex나 redux를 이용해서 에러팝업의 노출값을 관리한다면, action(& mutation)을 이용해서 처리한다.
root component의 상태로 저장/관리
이벤트 버스를 이용한다.
root component의 상태값으로 노출상태를 관리할경우, root component에서만 변경이 가능하다.
따라서 이벤트 버스를 이용해서 이벤트를 root component로 전달하고 root component가 이벤트를 받아 상태값을 변경하는 식으로 개발한다.
Event 버스는 결국 에러타입과 핸들러를 정의하고, 에러가 발생했을때 정의한 핸들러를 수행시키는 기능을 갖는 클래스라고 보면 된다.
- Window의 Event API를 사용해도 되고,
- SPA 전역환경에 Event를 관리하는 클래스를 싱글톤으로 직접 정의하여 사용할수도있다.
window 객체를 사용하면 이미 event와 관련된 API가 있기때문에 편하게 구현할 수 있으나, SPA Context를 벗어나는 외부영역이기에 화면이 SPA 단일 구성이 아닌 다른 영역들과 혼합된형태라면 사용을 지양하는게 좋다.
