오늘 한 일

  • 어제 가뜩이나 늦게 잤는데 오늘은 아침 일찍부터 어느 집 공사 소음 때문에 잠을 설쳤다. 소음의 진원지가 하필 일하는 방 바로 옆인 건지 유난히 더 크게 들렸다. 스크럼 때도 드릴 소리가 들어가고 나니, 문득 오늘 페어 작업에 방해가 될 것 같아 결국 집 근처 카페로 자리를 옮겼다. 근데 카페 음악 소리도 너무 커서 결국 페어는 물 건너 갔다...
  • 페어 대신 각자 파트를 나눠서 작업하기로 했다. 공교롭게도(?) 나는 또 다이얼로그 작업을 하게 되었는데 vms에 이미 들어가 있는 UI를 만져서 고치는 것은 새로 만드는 것과는 차원이 다르게 복잡했다. 그 와중에 식사하러, 식사 후 다시 일하러 계속 자리를 옮기게 되니 진득이 집중하기가 힘들었다. 차라리 늦게라도 출근을 할 걸 그랬다. 다행히 4시 반쯤 공사가 끝난다고 해서 집에 돌아오긴 했는데 지금 생각해 보니 괜히 또 중간에 움직였나 싶다.
  • 집에 온 직후 오늘 작업한 부분을 공유했는데 내 쪽에서는 한 게 별로 없어서 내일은 오늘 못 다 한 작업부터 시작하기로 했다.

오늘 배운 것

  • 어제 대강 살펴봤던 타입 추론과 타입 단언을 한번 더 찾아보았다. "컴파일러는 타입 추론을 통해 명시적인 타입 표기 없이도 타입 정보를 이해할 수 있다." "타입 단언을 통해 컴파일러에게 특정 타입 정보의 사용을 강제할 수 있다." 그러니까 value as Type 또는 <Type>value 형태로 쓰는 타입 단언은, value: type의 형태로 쓰는 단순한 타입 표기와는 완전히 다른 개념인 것이다. 
 

6.2 타입 추론 - ts-for-jsdev

하지만 만약 배열의 타입을 Array 로 추론한다면 어떻게 될지 생각해보자. getSoundFunction 함수는 Camel 타입을 인자로 받지 않는다. 그 때문에, dogAndCat 내에는 Camel 타입 값이 존재하지 않음에도 위의

ahnheejong.gitbook.io

 

6.3 타입 단언 - ts-for-jsdev

위 코드는 실제로 실행한다면 런타임 에러가 발생하지만, 타입 검사는 통과한다. 번거로운 타입 검사를 피할 수 있지만, any를 사용한 타입 단언은 어쩔 수 없는 경우를 제외하곤 피하는 것이 좋

ahnheejong.gitbook.io

 

오늘 한 일

  • 스크럼 끝나고 나서 한참을 기억 저편에 묻어두었던 깃훅에 대한 카드를 케이님이 다시 상기시켜 주셨다. 나 너무 부지런하지 못하다..😢  기억을 다시 되돌리기 위해 빠르게 빠르게 husky와 git hook pre-commit 문서를 펼쳐 놓고 스크립트를 짜 보려고 하며 오전 시간을 보냈다.
  • 그리고 오후에는 스프린트 미팅 - 승규님과의 페어 작업을 앞두고 사전 허들 - 셀러그로스 retrospective까지 해서 정신이 없었다ㅋㅋ.. 하루 웬종일 머릿속에 정보가 쏟아져 들어오는 느낌이었다. 물론 그거 다 흡수했다고는 안 했음
  • 스프린트 미팅에서는 SSO와 다른 서비스들과의 관계를 시각적으로 보여달라는 소연님의 말에 승진님이 관계도를 그리기 시작하셨고... 미팅은 1시간을 채웠다...
  • 카드가 나왔고 작업 estimation도 정했으니 승규님과는 내일부터 페어 프로그래밍을 진행하기로 했다. 일단 하기로 한 거고, 혹시 또  이런 프론트 작업에 페어 방식이 맞지 않는다면 작업 방식을 아예 바꿀 수도 있다. 드라이버는 페어 프로그래밍에 익숙한 승규님부터 시작하지만 나는 어떤 식으로 작업을 하는 건지 전혀 모르는 상태라 걱정 반 기대 반인 상태다.
  • retrospective는 처음 참여해 봤는데 너무 재미있었다. 나는 거의 한 마디도 안 하고 참관만 했지만 재미있었다. 혹시 그래서 더 재미있었을까..!? 다음 번에는 나도 조금 더 주도적으로 참여할 수 있길.

오늘 배운 것

  • 어제 썼듯이, 어제까지 작업한 모달, 그 모달에 이메일을 입력하면 비밀번호 초기화 페이지 링크 받는 것까지 확인해서 pr을 올렸다. 사실 작업 내용 자체는 별 게 없긴 했는데, 생각지도 못했던 부분에서 리뷰를 받았다. 타입스크립트 변수에 대한 타입 선언과 타입 추론 때문이었는데, 어차피 ""와 같이 값의 타입이 string이라는 걸 추론할 수 있는 변수인데 굳이 타입 선언이 들어갈 필요가 없다는 내용이었다. 타입스크립트니까 타입을 명시해줘야겠다고만 생각했을 뿐, 추론은 생각해 본 적이 없었다. 아래 링크에서 타입 추론 부분만 읽어 보았다. 머리에 들어올 것 같을 때 나머지도 마저 읽어봐야겠다.
 

TypeScript: 타입 추론과 타입 단언

TypeScript 를 도입하기가 망설여지는 이유 중 하나는 매번 일일이 변수를 선언할 때마다 타입을 선언해야하고 필요한 타입을 정의해야하는 비용에 대한 걱정일 것이다. 필요한 타입이 있을 때 타

hyunseob.github.io

 

 

오늘까지 한 일

  • 점점 TIL 쓰는 간격이 길어진다..ㅠㅠ연말 업데이트를 앞두고 퇴근 시간이 점점 늦어지는 와중에 체력이 받쳐주지 못하는 관계로 TIL 쓰는 걸 자꾸 미루다 보니 이렇게 되기에 이르렀다. 일하면서 찾아놓은 귀중한 링크들만 쌓여가고 풀지를 못하고 있다.. 그러니까 저질체력을 벗어나게 운동을 하자
  • 12월 업데이트를 제때 하기 위해 매일같이 야근을 하면서, 최근에는 기본 시스템 팝업창을 쓰지 않기 위한 커스텀 모달창을 제작했다. 모달을 띄워야 하는 페이지라면 어디에서든지 사용해야 하는 컴포넌트가 되므로, 그때그때 다른 속성들을 넘기기 위해 이런저런 props를 미리 정의해보았다. 그러는 과정에서 다른 모달 제작 사례들을 찾아봤고, props의 타입을 체크하는 방법을 리액트 공식문서를 통해 알게 되었다...! 공식문서 절대 놓지 말자
  • props의 타입을 미리 정해놓고 유효성 검사를 할 수 있게 되는데, 그렇게 하면 모달 컴포넌트에 props를 넘길 때 마치 외부 패키지를 갖다 쓰는 것처럼 vscode에서 알아서 미리 정의된 타입을 알려주는 툴팁을 띄운다. 와 뭐야 감동

오늘 그때 배운 것

  • 역시 공식문서! 두 번 보고 세 번 봅시다ㅠㅠ
 

Typechecking With PropTypes – React

A JavaScript library for building user interfaces

reactjs.org

  • 원리는 공식문서를 참고하되 이제는 내장함수가 아닌 패키지로 옮겨졌다고 하니 npm 링크도 함께 첨부합니다.
 

prop-types

Runtime type checking for React props and similar objects.

www.npmjs.com

+ Recent posts