1월 ~ 3월: 몸은 따뜻했지만 마음이 추웠던 겨울1월부터 3월까지는 취업을 위해 하루종일 집에 있었다.동시에 사이드 프로젝트를 2개를 수행해서 좀 바쁘기도 했다.지금 생각하면 취준의 조급함과 사람에 대한 그리움이 복합적으로 작용해서 상황을 고려하지 않고 무리한 스케줄을 잡았던 것 같다.취준 기간 동안 많은 지원과 면접 끝에 한 회사에 합격할 수 있었다.3월 8일에 최종 합격을 하고, 4월 1일 첫 출근날이 되기 전까지는 여태껏 만나지 못했던 사람들을 만나고, 푹 쉬며 하루를 보냈다.4월: 책을 많이 읽었던 달지금 회사는 온보딩 때 책 8권을 읽게 했다.부끄럽지만 지난 몇 년간 읽은 책의 총합이 5권은 될까?또한 기술서적만 읽었기 때문에, 교양서적은 전혀 보지 않았다.이번 기회에 꽤 많은 책들을 읽어볼 ..
성능 지표성능이란 단순하게 웹사이트가 얼마나 빠른가?를 의미한다.그런데 웹사이트를 '빠르게' 만든다는 것은 어떤 의미일까? 사실 성능은 상대적이다.- (고성능 디바이스, 빠른 네트워크)의 유저에게는 사이트가 빠를 수 있지만, (저성능 디바이스, 느린 네트워크)의 유저에게는 사이트가 느릴 수 있다.- 똑같은 시간에 로딩이 완료되더라도, 흰 화면이었다가 한번에 로드되는 것과 각 요소가 점진적으로 로드되는 것에 따라 후자가 더 빠르게 로드된다고 느낄 수 있다.- 사이트가 빠르게 보이더라도, 사용자 상호작용에 반응하지 않을 수도 있다. 따라서 성능을 이야기할 때는 지표를 이용하는 것이 좋다.또한 그 지표가 유용한지도 함께 고려하는것이 좋다.성능 지표를 측정하는법성능 지표는 일반적으로 두 가지 방법으로 측정한다...
들어가기웹페이지를 만들 때 랜딩 페이지의 로딩 시간은 중요하다.페이지 로드 속도가 느려지면 그만큼 사용자 이탈률도 높아진다.이때 문제를 해결하기 위해서 CDN 캐싱 등 여러 방법을 이용할 수 있지만,코드 레벨에서의 가장 대표적인 방법은 dynamic import이다.용어 정리용어부터 짚고 넘어가면 좋을 것 같다.초기 로딩 시간 줄이기에 대해 검색하면 code splitting, dynamic import, lazy loading 키워드들을 보게된다.이를 정리하면 다음과 같다:dynamic import는 lazy loading을 하기 위한 수단이고, lazy loading을 하기 위해서는 code splitting이 선행되어야 한다.즉 코드 레벨에서 dynamic import를 사용하면 번들링 때 code..
닌텐도 스위치가 떠오르는 표지를 가진 "이와타씨에게 묻다"는 닌텐도 전 CEO 이와타 사토루가 주변 인물들과 나눈 대화와 인터뷰를 엮은 책이다.어릴 적 닌텐도 DS로 마리오, 테트리스, 포켓몬 게임을 즐겼던 추억이 떠올라 재미있게 읽을 수 있었다. 이 책은 이와타 씨의 일대기와 함께 그의 철학과 생각을 전해준다. HAL 연구소의 아르바이트 직원부터 개발자, 닌텐도 경영자까지 각 역할에 맞는 마음가짐과 실제로 했던 행동들을 들려준다. 다음은 책을 읽으며 가슴에 와닿은 부분들이다. 1. 신입에게 가장 요구하는 것은 '아는척 하며 겉치레하지 말고, 모르는 것은 부끄러워하지 않는 마음가짐'입니다. 그리고 훈계를 친근하게, 하지만 진지하게 받아들이는 태도가 중요합니다. 2. 서로 선의를 지녔지만, 상대를 인정함으..
Query는 data fetching으로 받은 비동기 데이터이다.(GET)Mutation은 그 데이터를 업데이트하는 액션이다.(POST, PUT, DELETE) Mutation이 끝나면 대부분 Query에도 영향을 줄 것이다.예를 들어, `issue`데이터를 업데이트 하면 상위 개념인 `issues` 데이터에도 영향을 준다.따라서 React Query가 Mutation과 Query를 연결하지 않는다는 사실에 놀랄 수도 있다. 그 이유는 꽤 단순하다.React Query는 개발자에게 데이터를 맘대로 관리할 수 있도록 자유를 준 것이다.모든 상황에서 Mutation 이후 re-fetching(invalidation)이 필수는 아니다.예를 들어 Mutation api가 업데이트된 데이터를 반환해준다면, 그 데..
타입스크립트를 사용하는건 좋은 생각이다. 타입 안전을 싫어하는 사람이 있을까?버그를 미리 알 수 있고, 복잡한 앱의 구조를 타입으로 정의하여 그 부분들은 우리 머리 속에 담아둘 필요가 없어진다. "타입을 선언"한 것과 "타입 안전"한 것은 큰 차이가 있다.타입스크립트의 진정한 힘을 이용하려면 한 가지가 더 필요하다.신뢰하기우리는 타입 정의를 신뢰할 수 있어야한다.그렇지 않으면 타입은 단순 제안에 불과하고, 정확하다고 믿을 수 없다. - 가장 엄격한 타입스크립트 설정을 활성화하자.- typescript-eslint를 추가하여 `any`타입과 `ts-ignore`를 금지하자.- 타입 단언을 지양하자.제네릭타입스크립트에서 제네릭은 필수적이다.조금이라도 복잡한 걸 구현하려면 제네릭을 사용해야할 것이다. (라이브..
useQuery나 QueryClient.invailidateQueries 등 다양한 react-query 메서드에 파라미터로 넘겨주는 객체를 Query Options라고 부른다.// v5전에도 객체 형태로 넣을 수는 있었지만 이처럼 파라미터를 순서대로 넣는 방식이 널리 쓰였다.- useQuery(- ['todos'],- fetchTodos,- { staleTime: 5000 }- )// v5 부터는 객체 형식이 강제되었다.+ useQuery({+ queryKey: ['todos'],+ queryFn: fetchTodos,+ staleTime: 5000+ })이렇게 객체 형태를 파라미터로 넘겨주는 방식은 v5부터 강제되었는데, 어떤 이유 때문일까?1. 더 나은 추상화 (재사용) 모든..
나는 React Query를 좋아한다. React Query가 React앱에서 비동기 상태를 다루는 방식을 단순화하기 때문이다. 하지만 가끔 서버에서 데이터를 페칭해오는 것처럼 "간단한" 작업에는 React Query가 필요하지 않다고 주장하는 글들을 볼 수 있다.React Query가 제공하는 모든 추가 기능이 필요한 것은 아니니까, useEffect 안에서 fetch를 사용하는 것만으로도 충분할 때 굳이 서드파티 라이브러리를 추가하고 싶지 않다는 것이다. 이는 어느 정도 맞는 말이다.React Query는 캐싱, retry, polling, 데이터 동기화, prefetching 등 많은 기능을 제공한다.이러한 기능들이 필요하지 않다면 괜찮지만, 그렇다고 해서 React Query를 사용하지 말아야 한..
