회사에서는 Vue를 쓰고 있다. 그 중에서도 2 버전을 쓰고 있다.
Vue는 React와 달리 프레임워크라서, 개발자에게 사용성이 좋은 다양한 기능을 제공한다.
당연히 SPA의 특징 중 하나인 라이프사이클 훅 메소드를 제공하고,
watch나 computed, 그리고 extend와 함께 이 글의 주제이자 2버전에서만 지원하는 Mixins 이라는 기능을 제공한다.
오늘 팀원 중 한 명이 상수 값을 정의하고 export하는 js 파일을 만들어 필요한 부분만 import해 쓰자는 의견을 내놓았다.
다른 팀원이 Mixins에 넣으면 되지 않냐고 했고, 의견은 낸 팀원은 Mixins의 단점을 얘기하였다.
이 논쟁은 몇 달 전에도 대두되었다.
그 때는 자주 사용하는 함수들을 js파일로 빼서 사용하자는 것이었는데, 그 때도 Mixins에 넣어서 쓰자는 의견과, 그렇게 되면 리소스가 낭비되어 그럴 필요가 없다는 의견이 대립되었다.
결국은 js파일로 쓰는 것으로 결정이 났었는데, 이번에도 거의 같은 문제로 의견이 충돌한 것이다. 이야기가 길어지고 팀원 전체로 번지자 회의실에서 다 같이 이야기를 하게 되었다.
사실 난 이 논쟁이 있기 전까지 Mixins을 생각없이 편하게 사용하고 있었다.
하지만 Mixins을 지양하자는 측의 이야기를 들어보니, 납득이 되었다.
먼저 Mixins은, 재사용성을 위해 vue에서 제공한다. 공통의 변수가 함수를 정의해 놓고, 필요할 때마다 해당 컴포넌트에 Mixins, 말그대로 섞어서(합쳐서) 사용한다.
이런 Mixins의 장점은 분명하다. 제한 없이 Mixin 할 수 있어 공통의 기능을 가져다 쓰기 편하다.
극명한 장점이 있지만 단점이 여럿 존재한다.
- 믹스인에 존재하는 라이프사이클 메소드도 돌아야한다.
- 데이터나 메소드 이름이 중복되면 의도치 않은 오버라이딩 될 수 있다.
- 위의 경우 디버깅이 번거롭다.
- 상수 값 같은 디버깅에 필요없는 데이터를 Mixins에 넣으면 vue devtools에서도 보이기 때문에 안보여도 되는 데이터양이 많아 질 수 있다.
- 불변성의 특성을 가져야하는 데이터들이 믹스인에 있다면 쉽게 변할 수 있으므로 불변성에 위배된다.
이 단점들 때문에, Mixins을 설계한 Evan you도 Mixins의 실패를 인정하고 실제로 Vue3에서는 믹스인이 사라지고, Composition API라는 것이 Mixins을 대체하고 있다.
우리도 결론은 해당 기능에 대해서는 Mixins을 사용하지 않는 것으로 결론이 났다. 이미 만들어진 Mixins들은 어쩔 수 없지만 어차피 우리도 곧 Vue3로 마이그레이션할 것이기 때문에 Mixins에 정을 떼는 연습을 해야겠다.
