최근 나에게 고통을 줬던 코드를 기록 해본다.
무분별한 vuexfire
최근 진행한 프로젝트에서 vue, vuex, firebase, 그리고 vuexfire를 더해 사용하고 있다.
실시간성이 필요한 서비스다보니 firebase에서 제공하는 realtime 기능을 사용중이고 여기에 vuexfire를 얹은 상태다.
대략적으로 기록해보면, firestore의 collection과 document에 소켓이 연결되어 있고 여기에 vuexfire를 얹어, 소켓으로 연결된 데이터와 vuex store의 state를 바인딩 시켜주는 형태다.
연결되어있는 데이터들이 변화하는 순간 해당 데이터와 바인드된 vuex store의 state가 별다른 코드 없이 자동으로 변환된다.
vuexfire는 바인딩된 스테이트에 대한 mutation, action을 추상화 시켜주는 아이로 볼 수 있다.
얼핏보면 편리해보이지만, vuexfire가 너무 추상화 되어있어서 이벤트를 따라가기가 힘들었다…
가령, 게시판을 구현했다고 가정할 때, 게시글을 생성하고 그 게시글로 이동시켜야 한다고 하자.
‘글 생성 -> 글 생성 성공 -> 리다이렉트’ 정도의 흐름이 될텐데, vuexFire는 글 생성 요청 이후의 흐름을 따라가기가 힘들다.
이런 식이면, 결국 각각의 컴포넌트에서 내 손으로 직접 watch를 통해 ‘글’이라는 스테이트를 바라보게 만들고, 변화가 생겼을 때 무언가를 하도록 구현하게 된다.
watch를 남발하는 거 같아 찝찝하기도 하고, 무엇보다 이벤트 트랙킹이 안돼서 디버깅이 힘들다.
컴포넌트 내부 로직은 ‘뭐가 변했는지 모르겠는데 일단 변했으니까 나 이거 한다~’로 가득 채워지게 된다.
vuexfire만 걷어내도 firestore onSnapshot을 통해 적어도 create, update, delete 시점은 잡아낼 수 있다.
각각의 처리에 대한 비용이 들겠지만, 무분별하게 앱의 상태를 깜깜이로 업데이트 시키는 로직을 줄이는게 미래의 비용이나 정신 건강에 좋은 거 같다.
컴포넌트와 스테이트
컴포넌트를 프레젠테이션/컨테이너로 나누는 등의 방식은 종종 봤지만, 사실 필요성에 대해 이전 까지 깊이 체감은 못했었다.
최근에, 완전히 같은 페이지지만 권한에 따라 다른 데이터를 보여주는 작업이 있었다.
컴포넌트 자체가 큰 것도 문제였지만, 이 큰 컴포넌트가 한쪽 권한과 관련된 스테이트랑 한 몸 처럼 붙어있어서 재사용하기가 너무 힘들었다.
때어내려고 시도하는 과정도 너무 고통 스러웠고, 일정 압박에 못이겨 해당 페이지의 코드를 통째로 복사 붙여넣기해서 작업을 진행한 사실에 더 고통 받았다.
Resource
나의 고통