JavaScript 비동기 흐름 다시 보기 (07) - React Query는 Promise를 어떻게 UI 상태로 바꾸는가query function의 fulfilled와 rejected 결과가 React Query의 isPending, isError, data, error, isFetching으로 이어지는 흐름을 정리합니다.
JavaScript 비동기 흐름 다시 보기 (06) - fetch 에러는 어디서 throw해야 할까fetch가 HTTP 404와 500을 rejected Promise로 만들지 않는 이유와 response.ok 기준으로 throw할 위치를 정리합니다.
JavaScript 비동기 흐름 다시 보기 (05) - Promise.all, race, any, allSettled는 실패를 다르게 다룹니다여러 Promise를 함께 실행할 때 Promise.all, race, any, allSettled가 성공과 실패를 어떻게 다르게 결정하는지 정리합니다.
JavaScript 비동기 흐름 다시 보기 (04) - try/catch가 잡는 에러와 놓치는 에러동기 예외, await한 rejected Promise, 기다리지 않은 Promise 실패를 구분하며 try/catch의 실제 범위를 정리합니다.
JavaScript 비동기 흐름 다시 보기 (03) - Promise는 왜 나중에 실행될까: 이벤트 루프와 마이크로태스크 큐Promise의 then과 await 이후 흐름이 언제 이어지는지 call stack, event loop, microtask queue 기준으로 정리합니다.
JavaScript 비동기 흐름 다시 보기 (02) - async/await는 비동기를 동기로 바꾸지 않습니다async 함수가 Promise를 반환하고 await가 함수 내부 흐름만 기다린다는 점을 기준으로 async/await의 실제 역할을 정리합니다.
JavaScript 비동기 흐름 다시 보기 (01) - Promise는 값이 아니라 작업의 상태입니다Promise를 미래의 값보다 상태를 가진 비동기 작업으로 보고, pending/fulfilled/rejected와 then/catch/finally 흐름을 정리합니다.
Next.js의 use client는 CSR이 아니다Next.js App Router의 use client가 SPA의 CSR과 어떻게 다른지, hydration과 data fetching 관점에서 정리합니다.
디자인 시스템 다시 보기 (02) - 디자인 시스템은 어떻게 운영해야 살아남을까디자인 토큰, 컴포넌트, 문서를 누가 어떤 흐름으로 갱신해야 디자인 시스템이 실제로 유지되는지 정리합니다.디자인 시스템 다시 보기 (01) - 디자인 시스템이 있는데 왜 제품은 계속 어긋날까스타일 가이드, UI 키트, 컴포넌트 라이브러리, 디자인 토큰, 운영 원칙의 차이를 실무 맥락에서 정리합니다.
Pickle을 만들며 고른 기술들 (06) - 디자인 토큰과 아이콘을 왜 자동 생성 파이프라인으로 묶었을까Pickle에서 Figma 토큰을 CSS 변수로 자동 변환하고, 아이콘을 React 컴포넌트와 팔레트로 생성한 이유를 정리합니다.Pickle을 만들며 고른 기술들 (05) - 왜 Pickle은 익스텐션 UI를 iframe으로 격리했을까Pickle 익스텐션 UI를 iframe으로 격리한 이유와, 사이트별 스타일 충돌을 어떻게 다루게 되었는지를 정리합니다.Pickle을 만들며 고른 기술들 (04) - 익스텐션 로그인과 웹 세션을 왜 따로 다루지 않았을까Pickle에서 익스텐션 OAuth, PKCE, 세션 갱신, 웹과의 동기화 흐름을 어떤 기준으로 설계했는지 정리합니다.Pickle을 만들며 고른 기술들 (03) - 브라우저 익스텐션은 왜 일반 웹 앱과 다른 구조가 필요했을까Pickle 익스텐션이 iframe 대응, 백그라운드 코디네이션, 상위 프레임 렌더링 구조를 택한 이유를 정리합니다.Pickle을 만들며 고른 기술들 (02) - 왜 Pickle은 모노레포 구조가 필요해졌을까브라우저 익스텐션, 공개 웹, 클라이언트 앱이 함께 커지면서 왜 Pickle이 모노레포와 shared contracts를 택하게 되었는지 정리합니다.Pickle을 만들며 고른 기술들 (01) - 작은 저장 문제에서 제품 구조까지브라우저 익스텐션으로 시작한 Pickle이 웹 대시보드, 검색, 동기화, 모노레포 구조로 커지며 생긴 설계 기준을 정리합니다.
패키지 매니저부터 모노레포까지 (05) - 패키지 매니저 이야기가 왜 monorepo로 이어지는가패키지 매니저, workspace, 의존성 경계 문제를 따라가면 왜 monorepo 구조를 함께 이해해야 하는지 정리합니다.패키지 매니저부터 모노레포까지 (04) - workspace는 왜 필요해졌나패키지가 여러 개로 나뉘기 시작하면 왜 workspace가 필요해지는지, 단일 프로젝트 구조의 한계와 함께 정리합니다.패키지 매니저부터 모노레포까지 (03) - npm, Yarn, pnpm은 왜 서로 다른 길로 갔을까빠르다는 이유만으로 Yarn과 pnpm을 골랐던 시기를 지나, 이제는 설치 방식과 의존성 모델의 차이로 패키지 매니저를 이해하게 되었습니다.패키지 매니저부터 모노레포까지 (02) - 패키지 매니저는 왜 npm 하나로 끝나지 않았나npm이 기본 축인데도 Yarn과 pnpm 같은 도구가 계속 등장한 이유를 속도, lockfile, 설치 모델 문제를 중심으로 정리합니다.패키지 매니저부터 모노레포까지 (01) - npm이란 무엇인가npm을 단순한 설치 명령어가 아니라, registry와 package.json, 의존성 관리 흐름까지 포함한 기본 축으로 다시 정리합니다.
중첩 모달 문제를 라이브러리로 풀면서 배운 것들react-layered-dialog를 만들고 공개하면서, 다이얼로그 문제를 풀 때 무엇을 남기고 무엇을 버려야 하는지 다시 정리했습니다.
프론트엔드 데이터 패칭 다시 보기 (05) - Next.js App Router에서는 이 패턴을 어떻게 다시 설계해야 하는가App Router에서 서버 컴포넌트, DAL, 최상단 orchestration, client cache의 역할을 어떻게 나누면 좋은지 정리합니다.프론트엔드 데이터 패칭 다시 보기 (04) - prefetch와 hydration은 언제 도움이 되고 언제 구조를 흐리는가prefetch와 hydration이 초기 로드에 왜 강한지, 그리고 컴포넌트가 많아질수록 왜 중복 요청과 serialization 비용, ownership 혼란으로 이어질 수 있는지 정리합니다.프론트엔드 데이터 패칭 다시 보기 (03) - TanStack Query는 서버 상태를 어떻게 추상화하는가query key, cache, staleTime, mutation, invalidation이 왜 한 세트로 묶이는지, TanStack Query가 서버 상태를 어떤 모델로 다루는지 정리합니다.프론트엔드 데이터 패칭 다시 보기 (02) - 서버 상태를 다룬다는 것은 정확히 무엇인가캐시, stale data, refetch가 왜 한 묶음으로 따라오는지, 서버 상태를 로컬 상태와 같은 방식으로 다룰 수 없는 이유를 정리합니다.프론트엔드 데이터 패칭 다시 보기 (01) - React에서 비동기 데이터 처리는 왜 자꾸 복잡해지는가useEffect 하나로 시작한 데이터 패칭이 왜 로딩, 중복 요청, stale data, 화면 간 불일치 문제로 빠르게 커지는지 서버 상태 관점에서 정리합니다.
《npm Deep Dive》를 읽고 정리한 라이브러리 설계의 기준패키지를 몇 번 배포하고도 왜 불안했는지 설명하지 못했습니다. 《npm Deep Dive》를 읽고 라이브러리 설계 기준을 다시 정리했습니다.