This Week I Learned
- React
- 여러번의 렌더링에 걸쳐서 Hook이 기억되는 원리
- useEffect Hook의 배열의 정확한 의미
- 기본적으로 useEffect의 콜백은 매 렌더링 시에 실행
- 배열 안의 모든 요소가 같을 경우, 렌더링 시 useEffect의 실행을 Skip 한다는 의미
- 빈 배열이면 한번만 실행되고, deps안의 요소가 하나라도 변하면 다시 실행된다고 이해했었는데 위와 같이 이해하는 것이 더 명료하고 정확한 것 같다.
- Script 태그 async, defer attribute
- html을 파싱하는 중간에 만난 script 태그의 다운로드와 실행 시점을 제어한다.
- 스터디 원 분이 정리해서 알려주셔서 잘 배울 수 있었다.
이번주의 느낀점
- 오늘(2/1)까지 면접을 3개 보았는데, 모두 상당히 수준이 높고 좋은(취준생 입장에서는 까다로운... 어려운...) 질문을 많이 던져주셨다. 내가 알던 것이 아니라는 것을 많이 깨닫게 해주는 포인트들이 많았다.
- 단순히 특정 개념을 알고 읊는 것이 아니라, 왜 그 기술을 써야하고 / 장단점이 무엇이고 / 어떤 기술과 비교되는지 많이 질문받았던 것 같다. 누군가가 깔끔하게 정리된 것을 외우는 것 보다는 완벽하지 않더라도 자신만의 말로 생각을 정리해두는 것이 좋은 것 같다.
- 개념을 암기하기만 한 것은 외운 단어와 개념들을 그럴싸하게 말할 수는 있지만, 정작 추가 질문이 들어오면 당황하고 얼버무리게 되는 것 같다. 오히려 개념을 이해하고 정리할 수록 쉬운 말로 설명할 수 있고, 적절한 비유를 들어서 설명할 수 있게 된다.
- 스터디원 분들이 직접 코드 snippet을 짜고 돌려보면서 개념을 정리해오신 것들이 인상깊었다. 읽기만 하고 말로만 아는 개념은 오래 남지 않는 것 같다. 면접 준비를 하면서 많은 범위의 개념들을 알아야 해서 주로 여러 글들을 읽고 정리하면서 bullet point로 나만의 언어로 정리했었는데, 스터디원 분들처럼 코드를 직접 짜고 남기면서 정리해보아야겠다.
- 개인 프로젝트의 데이터 캐싱 부분을 한참 고민하다가 구현을 끝냈다. 간단한 작업이라고 생각했는데, UX를 생각하니 고민할 부분들이 정말 많았다.
- Pre-fetch와 어제, 내일 데이터 캐싱을 어떻게 구현할 것인지
- Recoil에서 적용하는 상태 트리에 의존
- derived state인 selector에서는 input으로 특정 값을 넘길 수 있다.
- 어제와 오늘의 날짜를 미리 넣어서 상태 트리에 필요한 값을 로딩시켜 놓는다.
- 별도로 화면에 표시되는 date 상태가 존재함에도 불구하고, 자동으로 atom에서부터 연동되는 것이 아니라 input으로 넣어주어야 하는 단점이 있다. atom 값은 실제로 UI에서도 사용되기 때문에 미리 화면 상의 날짜를 어제, 내일로 돌려볼 수는 없이 때문이다. 캐싱을 하고자 이렇게 구현하는 것은 Recoil의 상태 트리를 무시하는 안티패턴이 되는 것 같아서 기각하게 되었다.
- Custom Fetch 함수 레이어에서 캐싱 적용
- 결국 돌고 돌아서 fetch를 수행하는 함수를 적용하는 쪽에서 캐시를 적용하였다.
- 여러번 구현을 바꾸어 봤는데, React Component 쪽에는 똑같이 getWorkouts(date)와 같이 호출하도록 API를 노출하는 것이 간결하다고 느껴졌다. 기존에 체류하던 날짜에서는 데이터 변경이 있을 수 있어서 getWorkouts(prevDate, nextDate)과 같은 식으로 전달해서 prevDate의 캐시를 갱신하는 방식을 고려했는데, 컴포넌트와 API 호출 단의 분리가 깨지는 느낌이 들었다. 결국 date는 원하는 데이터의 날짜만 받고, 캐시 갱신은 PATCH 요청 시에 처리하는 것으로 했다.
- Recoil에서 적용하는 상태 트리에 의존
- date 변경에 따른 비동기적인 데이터 변경으로 인한 로딩시간을 어떻게 처리할 지
- Recoil과 React Suspense를 연동해서 fallback UI 보여주기
- 날짜 변경이 있을 경우 날짜의 파생 state(selector)인 데이터가 자동으로 업데이트를 시작하게 되고, 데이터를 가져오는 중이라서 렌더링이 미완료인 동안은 Suspense가 잡아서 로딩중을 표현하는 fallback UI를 표시
- JSX 내에서 loading 중이라는 상태를 별도로 관리하고 if~ else~문 처리를 하지 않아도 되어서 더 명료하다고 느꼈다.
- 단점은 짧은 시간동안(1초 이내) 비동기 처리가 발생해도 fallback UI를 잠깐이라도 띄우기 때문에, UI가 0.x초 동안 잠깐 나왔다가 사라져서 화면이 깜빡거리는 효과가 생겼다.
- 아예 Suspense 상태를 없앨까 라고 잠깐 고민하다가, 정상적인 컴포넌트에 CSS로 fade-in 효과를 주어서 전환이 자연스럽도록 유도했다. 하지만 이 방법도 그냥 흰 화면이면 괜찮지만 fallback UI에 spinner가 포함되어서 잠깐 점이 보였다 사라지는 문제가 생겼다.
- fallback에서 사용되는 컴포넌트에 0.8초 딜레이를 걸어서, 0.8초 동안 빈 화면을 표시하면서 대기하다가 그 이후로는 spinner를 표시하게 만들었다. 드디어 만족! UX에서 사용자의 생각의 흐름이 끊기는 시간의 상한이 1초라고 보았는데, 조금 더 여유롭게 0.8초로 잡았다. 0.8초 이상으로 가면 로딩 UI가 뜨기 때문에 사용자가 이상하다고 생각하지 않고 로딩 상태를 인지할 수 있도록 유도했다.
- Recoil 상에서 loading 상태를 유지하기 보다는, 별도의 비동기 함수에서 새로운 상태를 기다리고 업데이트 받아서 상태를 바꾸어 줄지
- 특정 일자에 대한 데이터를 date에서 파생된 상태가 아닌 별도의 독립된 상태로 관리하고, 수동으로 업데이트 하는 방식
- 위의 고민과 같이 역시 Recoil 상태 트리를 활용하지 못하는 느낌이 들었다.
- Recoil과 React Suspense를 연동해서 fallback UI 보여주기
- 데이터에 대해서 변경 요청을 DB에 보냈을 때, 어떤 방식으로 캐시를 업데이트 시킬 지
- 캐시에서 변경 요청된 데이터의 자리를 비워주고, 다시 DB에서 데이터 받기
- 원래는 캐시를 key - value 쌍 전체를 날려버리고, 다시 key로 Query를 날려서 업데이트 된 데이터를 받으려고 했다.
- 하지만 POSTMAN으로 PATCH 요청을 보내보니, 이미 업데이트 된 객체가 오도록 되어있었다. 내가 짠건데 기억을 못했었다...
- Update 처리 이후에 200 Okay 코드와 변경 완료된 데이터를 받으니 통째로 업데이트 전 객체와 바꾸어주기만 하면 되었다.
- 예전에 POST, PUT, PATCH 요청에서 왜 종종 응답으로 GET와 동일한 body를 주는 지 의아했었다. 이미 예전 데이터와 변경정보를 알고 있는데, 클라이언트가 알아서 업데이트 하면 되지 왜 굳이 DB에서 한번 더 받아오는 걸까? 불필요한 네트워크 낭비가 아닌가? 라고 생각했었는데 이런 식으로 쓰는 경우가 있어서겠구나라고 생각했다. 조금의 body 용량을 사용해서 프론트엔드 처리를 줄이고 클라이언트 - 서버 데이터가 동일함을 보장하는 느낌이다.
- 기존 정보와 업데이트 요청 시의 정보를 조합해서 DB에 갔다오지 않고 캐시를 업데이트 하기
- API를 디자인 할 때, PUT보다는 PATCH 요청으로 필요한 정보(운동한 횟수)만 body로 보내도록 했기 때문에 캐시를 끝까지 depth를 파고 들어가서 변경된 좁은 부분을 찾고 바꾸어주어야 했다.
- 여러모로 코드가 번잡해지기도 하고, DB와의 정합성이 깨질 까 걱정되어서 기각했다.
- 캐시에서 변경 요청된 데이터의 자리를 비워주고, 다시 DB에서 데이터 받기
- Pre-fetch와 어제, 내일 데이터 캐싱을 어떻게 구현할 것인지
이번주의 칭찬
- 개인 프로젝트의 캐싱, prefetch와 관련해서 깊게 고민해본 것 같아서 뿌듯하다.
- 비록 완벽하지는 않았지만, 힘든 면접 3개를 소화해낸 스스로에게 칭찬
개선점 & Reminder
- 월요일 오전에 면접이 또 잡혀서 블로그 글이 우선순위에서 밀렸다... 반성...
- 스터디 자료 정리할때 응용해서 직접 코드로 짜고 기록하면서 하기
- 일주일치를 쓰니까 매일 배우고 했던 것들이 완벽하게 기억이 나지 않는다.
- 면접도 거의 끝났는데 다시 일일 회고로 돌아갈지 고려해 봐야겠다.
- 개발 서적 이것저것 보지 않고 하나 집중해서 보기
'Logs' 카테고리의 다른 글
주간 회고 - 2021.02.08 ~ 2021.02.14 (0) | 2021.02.14 |
---|---|
주간 회고 - 2021.02.01 ~ 2021.02.07 (0) | 2021.02.10 |
주간 회고 - 2021.01.18 ~ 2021.01.24 (0) | 2021.01.24 |
Daily Log - 2020.07.14 (0) | 2020.07.14 |
Daily Log - 2020.07.13 (0) | 2020.07.13 |