흑백과 디지털

이제 vuetify를 이용해서 vue 를 사용한지 1년은 된 것 같다. 그런데도 새로운 것을 배우게 된다. 그냥 무의식적으로 css 설정에서 deep (vue2 에서는 v-deep 로 알고 있다.) 를 사용했는데, 이것을 사용하는 이유를 인식하게 되었다. 난 이용도를 제대로 인식하지 못하다보니 deep 설정이 필요 없는 곳에도 난발하고 있었다.

vue에서 일반적으로 css 스타일을 지정할 때 <style scope> 처럼 scope 라는 구문으로 css 범위를 해당 파일로 제한하게 된다. vue3 를 기준으로 html 태그를 추가하면 자동으로 태그 옆에 data-v-f2c7905d 같은 랜덤함 attribute 가 동일한 파일범위에 같은 값으로 추가된다. 그래서 css 설정에 보면 자동으로 [data-v-f2c7905d] 같은 css selector 가 자동 추가된다. 이렇게 추가되다보면 현재 작업하는 파일과 다른 파일로 분리된 vue 컴포넌트는 다른 랜덤 data-v-XXXXXX 가 생성된다. 그러면 현재 범위를 기준으로 하위 컴포넌트의 스타일을 변경하지 못한다. 이러한 제한을 벗어나게 하기 위해 deep 구문을 이용해서  .test :deep([type="text"].v-field__input) 
으로 deep 를 설정하게 된다. deep 내에 둘러싸인 부분은 하위 컴포넌트를 접근하기 위한 css selector 조합인 것이다. 어째든 이렇게 deep 로 둘러싸인 부분은 자동으로 [data-v-XXXXXX] 같은 것이 추가되지 않는 것 같다.(정확한 동작 원리는 모르겠지만 내 테스트로는 이렇다.)
대충 내 느낌으로는 왼쪽 처럼 사용하면 오른쪽 처럼 자동으로 css selector 가 변화는 느낌이다. 
.test :deep([type="text"].v-field__input)   => .test  [data-v-f2c7905d]  [type="text"].v-field__input
.test ([type="text"].v-field__input)  => .test [type="text"].v-field__input[data-v-f2c7905d]

[type="text"].v-field__input 부분이 하위 컴포넌트 부분이라면  [data-v-f2c7905d] 가 아닌 다른 랜덤한 번호가 붙기 때문에 의도대로 css 셀레팅이 되지 않을 것이다. 이렇기 때문에 deep 를 사용해서 자동 추가를 막는 것 같다. 

어째든 하위 컴포넌트 속성을 selector 하는 부분이 없다면  이 구문이 필요 없는 것이었다. 내가 vuetify 를 이용하고, 이 컴포넌트들의 디자인을 더 작게 만들일이 많다보니 deep 를 많이 사용했던 것이다. 

이것을 오늘에서야 인식하게 되었다니, 나도 참 대충 프로그래밍 짜는 것 같아서 부끄럽다. 

* 퇴근시간 전에 확인 요청하는 경우
  - 내가 다니는 회사가 09:00 ~ 10:00 사이에 출근해서 근무시간 8시간만 채우고 퇴근하는 방식이다. 나는 아침 09:00부터 업무를 시작하는 편이다. 그러다 보니 17:30 분 이후에 업무 요청이 들어오는 경우도 꽤 많다. 이 시간 급하게 요청하면 내 퇴근 시간이 늦어지게 된다.

* 스크린샷만으로 버그 리포팅하는 경우
 - 어느 순간 사내 웹사이트 기능이 엄청 많다보니 화면 만으로는 어떤 URL 인지 알 수 없다. 그리고 특정 데이터를 가진 object 에서만 에러가 발생하는 경우가 많아서 전체 URL을 알아야 재현되는 버그도 많다. 그런데 꼭 스크린샷만으로 버그 리포팅 하는 사람이 많다. 이 때마다 버그 리포팅하는 크롬 확장을 만들어야 겠다는 생각을 하게 된다. 

* DM으로 버그 리포팅하는 경우
 - "스크린샷만으로 버그 리포팅하는 경우"가 발생하는 이유이기도 하다. 분명 버그 리포팅하는 양식을 만들어 두었는데, 그것을 무시하고 DM으로 버그리포팅 하는 경우가 많다. 이런 경우 재현이 싶지 않아서 다시 확인하게 된다.

오늘도 내 퇴근시간전에 DM으로 버그 리포팅이 발생해 이 글을 올린다. 너무 많은 기능, 1회성으로 요청하고 사용하지 않는 기능, 너무 다양한 입력 때문에 버그가 너무 많다. 물론 내가 게을러서 Testcase 환경을 구축하지 못했기 때문에 발생하는 문제도 있다. 이제는 뭔가 근본적인 해결책이 필요할 것 같다. 고민해봐야겠다. 

 회사내 관리사이트의 UI 를 다시 만들고 있는데, vuetify3 + typescript 를 사용하면서 개발하고 있었다. (기존 UI는 Boostrap4 였다.) 그런데 typescript 가 사용하기 쉽지않아 꽤 많은 페이지를 javascript만으로 개발하고 있었다. 그러다 오늘 완전히 typescript 를 걷어내기로 했다.( 어차피 회사내 개발자가 나 밖에 없기 때문에 나혼자 결정하면 되었기 때문에 바로 결정하고 걷어내는 작업을 했다.)
  내 경우, 이 사내 관리사이트 UI 는 typescript 가 맞지 않은 것 같다. 꽤 많은 부분이 any 타입으로 되어 있고, 기존 library 를 사용할 때 불편함이 크고, 나 자신도 typescript 사용법이 익숙하지 않았다. 그래서 typescript 를 사용해서 얻는 이득보다 시간 소모가 더 큰 것 같아 그냥 javascript 만을 사용하기로 했다. 그리고 어차피 꽤 많은 부분에서 javascript 를 사용해서 제거하는 것도 큰 어려움이 없었다. 

 typescript 는 뭔가 언어 이름이 잘못된 것 같다. script 언어가 갖는 장점이 week typing 과 메모리관리(할당과 해제)인데 이 중 하나인 week typing을 포기하면 이게 굳이 script 인가 싶다. 그냥 typelang 이 되어야 할 것 같다. 

 어째든 내가 강하게 하고 싶은 부분만 strong type을 쓰면 좋은데,  모든 변수, 함수에 대해 typing을 지정해야 하는게 너무 불편했다. Rust 언어의 경우 강력한 추론기능 때문에  타입이 추론되는 곳은 굳이 type을 적지 않아도 된다.(이런 기능이 vscode 와 연동되기 때문에 엄청 편리했다. ) 이런 식의 뭔가 좋은 tool 이 나오지 않는한 나 혼자 하는 프로젝트에서는 더 이상 typescript 를 시도하지 못할 것 같다. 이미 나에게는 javascript 로 충분하기 때문에 더더욱 이런 결정을 하게 된 것 같다.