월간 회고록 - 23.03

se-een·2023년 3월 30일
1
post-thumbnail

👍 Liked

지속 가능한 도시락

선릉 캠퍼스 기준 점심값 비용이 평균 1만 ~ 1.2만에 달한다. 여러 지원비를 받고 있는 상태라 생활비는 괜찮은 편이지만 저축에 욕심이 난다. 도시락을 먹으면 4천원 선에서 해결 가능하니 최대 8천원가량 저축 가능한 셈.

지속 가능한 것이 관건이다. 간편하고 쉽고 빠르고! 전자레인지 볶음밥 + 닭가슴살 조합 꽤 괜찮다. 당분간 이 조합으로 살아볼 예정이다.

출입증 사진

2월 중순쯤 찍었던 걸로 기억하는데 꽤 만족스럽게 나왔다. 사원증은 아니지만 무언가 목걸이에 걸고 다니니 소속감도 생기고 좋다.

근데 아직은 적응이 안 되서 그런지 은근 무겁다.

📚 Learned

옵저버 패턴에 key, value 더하기

페어 프로그래밍을 하던 중이다. 옵저버 패턴을 사용해서 리렌더링을 관리하기로 했는데 이전에 렌더링 효율과 관련해서 문제가 여럿 보였다.

이야기가 오고가던 중, 파트너가 observing 할 state를 객체의 key로 관리하는 것이 어떻겠냐고 제안했다. 적용해보니 기존보다 훨씬 유연해졌다.

observing할 state를 선택할 수 있기에 도메인 분리가 덜 되더라도 (도메인 내에서 관찰할 state 값이 여러 개라도) 추가적인 로직(조건문 등) 없이 notify가 가능하다.

프록시 객체와 유사해져가는 느낌이다.

Custom Element & Shadow Dom

컴포넌트 단위로 미션을 진행하다보니 DOM 렌더링 최적화와 컴포넌트, 이벤트 바인딩 이 두 가지를 동시에 챙기려다보니 어려움이 있었다.

예를 들어 MovieList에서 MovieItem을 20개씩 렌더링 해야한다고 가정하자. appendChildinsertAdjacentHTML든 하나씩 DOM에 그려준다면 그 과정을 20번 반복해야하므로 애플리케이션 속도에 지장이 생긴다. 그래서 20개를 미리 string으로 그려놓고 1번만 DOM에 그려주는 방식으로 진행했다.

이렇게 진행하면 MovieItem이 생성되는 시점은 DOM에 없기 때문에 이벤트 바인딩이 까다로워진다. 그렇다고 MovieList에 이벤트를 달고 event.target으로 하나씩 검사하자니 MovieItemid를 일일히 비교하는 것도 꽤 복잡하고, MovieItem이 아닌 곳에서도 이벤트가 발생한다.

따라서 커스텀 엘레먼트를 도입했다. 커스텀 엘레먼트의 존재는 이전부터 알고는 있었지만, 굳이? 써야하나 싶어서 미루고 미루다가 위와 같은 문제점들을 마주하고 나서 사용하게 되었다.

connectedCallback, attributeChangeCallback다양한 컴포넌트 생명주기 메서드를 사용할 수 있기에 DOM 렌더링 효율성을 챙기면서 이벤트 바인딩까지 보다 쉽게 가능했다.

쉐도우 돔은 사용하지 않았는데 캡슐화 측면에서 이점이 있어 미션 리팩토링 때 사용해볼 예정이다.

나만의 웹 컴포넌트란

어느 정도 틀을 잡았다. 결국에 프로그래밍에 정답은 없듯이.. 컴포넌트에도 정답이란 없는 것 같다. 상황에 맞게 유연하게 적용하면 된다.

컴포넌트간 의존성, 렌더링 효율성, 이벤트 바인딩 이렇게 세 가지를 중점적으로 상황에 맞게 알맞는 컴포넌트를 작성하는 것이 좋겠다.

이는 추후 학습 로그 시리즈에 정리해서 작성해보겠다.

Promise, async/await

딥 다이브를 여러 번 봤다만, 유독 이 부분이 약했다. 읽어도 잘 기억도 안나고.. 좀 어렵다고 느껴졌다. 그나마 블로그를 정리하면서 Promise에 대해서는 어느정도 빠삭한 편인데 async/await는 잘 몰라서 비동기 미션이 나왔을 때 살짝 겁 먹었다.

우테코 수업시간에 이와 관련한 미니 미션을 수행하였는데, 덕분에 확실하게 이해할 수 있었다. 별거 없었다. 이는 여기에 정리해보았다.

모달 UX 개선

모달이라고 하면 보통 광고 팝업창, 로그인 창을 생각해볼 수 있을 것이다. 개인적으로 모달이란게 사용자의 행동을 제한하는 것이기에 모달을 빨리 닫을 수 있는 방법을 여러 개 준비하는게 UX 측면에서 좋다고 생각한다. 물론 사용자가 선택하여 모달 창을 띄운 것이라면 꼭 사용자의 행동을 제한하는 행위라고 볼 수는 없겠다.

보통은 모달을 닫으려면 닫기 버튼을 눌러야만 모달을 닫을 수 있는데 (특히 광고창 😡) 이는 매우 귀찮은 일이다. ESC를 눌러서, 또는 모달 외의 영역을 클릭해서 닫을 수 있도록 한다면 UX가 많이 향상될 것이다.

모달을 dialog 태그로 작성하면 매우 쉽게 해결할 수 있다. 기본적으로 ESC를 누르면 모달이 닫힌다. (focus 되어있다고 한다.) 그리고 닫기 버튼 또한 form 태그와 button 태그를 사용해서 쉽게 구현할 수 있다.

모달 외 영역 클릭 시 모달 닫기 기능 또한 쉽게 가능하다. dialog 태그에 클릭 이벤트를 리슨해보면 모달 외 영역도 dialogtarget 되는 것을 확인할 수 있다.

그래서 dialog 태그 바로 아래에 div 태그로 모달 요소들의 container 역할을 할 수 있도록 하고, dialog가 클릭될 때 모달을 닫도록 하는 기능을 작성하면 모달 외 영역을 클릭 시 모달을 닫을 수 있다.

이는 학습 로그 시리즈나 기능 구현 팁(?) 시리즈에 정리해서 작성해볼 예정이다.

💦 Lacked

타입스크립트

타입스크립트를 단 한 번도 써본 적이 없기 때문에 타입 에러가 나면 어디서부터 건드려야할지 전혀 감이 안 잡힌다. 타입 가드니 타입 추론이니.. 제네릭.. 어렵다.

노마드 코더 타입스크립트 기초 강의를 들었는데 기초 문법은 어느 정도 파악했다만 미션에서 적용이 어렵다.

'타입스크립트 프로그래밍'이란 책을 읽으면서 기초 문법을 다지고 있다. 추후 방학 때 미션 리팩토링을 통해 타입스크립트를 다지고 '이펙티브 타입스크립트' 책을 '모던 자바스크립트 딥 다이브' 시리즈처럼 블로그에 정리해볼 생각이다. (Chat GPT보다 나은 블로깅이어야 할텐데..🤔)

브라우저에서 비동기 동작

사실 이 부분은 학습 로그 시리즈에 작성했던 내용이다. 하지만 1 Depth 정도의 내용인 것 같다.

얼마전 레벨 인터뷰를 포비와 5명의 크루들과 함께 했었다.

포비가 자바스크립트 엔진이 싱글 쓰레드임에도 setTimeout과 같은 비동기 작업을 어떻게 돌리고 있는지 그 과정에 대해서 좀 더 깊게 파볼 것을 권장했다.

Web API가 setTimeout의 타이머를 돌려주는 것으로 알고있었는데 이는 너무 추상적이었던 것 같다. '워커 쓰레드'란 키워드를 던져주셨는데 더 자세히 알아봐야겠다.

Node 환경에선 어떻게 작동하고 있는지도 알아볼 것!

실행 컨텍스트와 this

이 역시 레벨 인터뷰 때 포비가 물어봤던 내용이었다. 실행 컨텍스트 렉시컬 환경의 다양한 슬롯 중 그 어딘가에 this가 있는 것으로 알고 있었다.

질문이 심층적으로 가니 점점 내 답변이 '그럴 것이다.'라고 추측성 발언을 하고 있었다.

'코어 자바스크립트' 책에 잘 나와있다고 들었다. 집 앞 도서관에 여러 권 있더라..🤩 방학 기간동안 읽어봐야겠다.

레벨 인터뷰에서의 피드백

레벨 인터뷰 때 피드백 받았던 내용인데, 답변을 하기 전 반복적으로 '어..', '음..' 이런 추임새(?)를 하는 안 좋은 습관이 있었다.

예전에 대학 입시 때 고쳤다고 생각했던 습관이었는데 아닌가 보다. 이 부분은 다음 레벨 인터뷰 때 의식하면서 고쳐봐야겠다.

추가로 묻는 질문에 대해서만 간단명료하게 답변할 필요가 있어보인다. 나는 보통 무언가를 설명할 때 비유를 많이 하는데 답변이 너무 길어져 인터뷰어들의 집중도를 떨어뜨릴 수 있다.

좋은 인터뷰어라면 거의 반드시 꼬리 질문을 할 것이기에, 그들의 궁금증을 유발하는 간단명료한 답변을 하도록 연습하자.

Custom Event

레벨 1 마지막 미션 때 커스텀 이벤트를 사용한 크루들이 몇몇 보였다. 아직 사용해보진 않아서 정확하게는 알지 못한다.

하지만 커스텀 이벤트를 사용해서 옵저버 패턴 또는 프록시 패턴을 대체할 수 있어보인다. 미션 리팩토링 때에 적용해볼 것! 사용해보면서 장점과 단점을 정리해봐야겠다.

Headless Component

컴포넌트의 재사용성 또한 중요하다. 이전까지 설계한 방식은 컴포넌트의 UI 부분을 template 메서드 부분이나 render 메서드 부분에 작성하였는데, UI 변경 시 재사용이 어려워보였다.

props로 UI부분의 attribute를 넘겨주는 방식도 고려해보았는데 가능은 하다만 UI 변경 사항이 세세하고 많다면 props가 장난아니다.

우테코 수업자료에 있던 이전 기수분들의 테코톡을 보면서 Headless Component에 대해서 알게 되었는데 내가 고민하고 있던 부분의 해답이 될 수 있을 것 같다.

미션 리팩토링 때 적용해보자.

profile
woowacourse 5th FE

0개의 댓글