태그
28개의 글
useContext 가 if 안에서 막힐 때 use 가 풀어주는 자리예요
useLayoutEffect 를 언제 꺼내야 할지 결정 트리로 정리해봐요.
children 에 props 를 꽂으려는 순간, React 19 의 unknown 이 막아서요.
같은 데이터 페칭처럼 보여도 두 라이브러리의 자기 소개부터 톤이 달라요.
Suspense는 fallback 스위치가 아니에요. TanStack Query가 그걸 따라간 모양도 봐요.
React가 렌더를 중단하는 사이, 외부 store 값이 바뀌면 화면이 갈라져요.
onChange 마다 리렌더되는 게 부담일 때, 비제어가 답이 되기도 해요.
Flux 저장소는 archive 됐어요. 근데 상태 관리 얘기할 때 왜 여전히 Flux부터 나오죠?
state, props, 부모 중 무엇이 트리거였는지 헷갈릴 때 보세요.
fallback 하나 추가했더니 LCP가 뒤로 밀렸어요. 경계 위치를 다시 재봐야 해요.
Suspense를 fallback 넣는 스위치로 썼다면, 경계 한 번쯤 다시 봐야 해요.
수천 행짜리 리스트가 뻑뻑해질 때, 가상화는 뭘 빼고 뭘 다시 채워야 하는 걸까요
Object.assign을 namespace로 고치면 RSC는 풀려요. 근데 API와 Context, 번들 쪽이 동시에 흔들려요.
css prop을 쓰면 스타일이 알아서 적용되죠. 그 사이에서 Emotion이 하는 일을 따라가 봅니다.
startViewTransition을 React에서 그냥 쓰면 타이밍이 어긋나요. flushSync로 맞추는 법부터 정리했어요.
두 패턴이 비슷해 보일 때, 어디서 갈리는지 짚어볼게요.
fetch 만 쓰다 보면 신호가 어디까지 닿는지 잘 안 보이거든요.
큰 store 를 자르거나, 작은 atom 을 합치거나. 두 라이브러리는 출발점이 정반대예요.
리스트 렌더링용이라 여겼던 key가 state 리셋 도구라는 사실, 놓치셨을 수 있어요.
Redux의 store.subscribe와 Zustand의 selector, 이름만 바꾼 옵저버 패턴이에요.
부모에서 자식의 focus나 scroll을 호출해야 할 때 쓰는 훅이에요.
한 객체로 묶어 넘기면 dispatch만 쓰는 컴포넌트까지 리렌더돼요.
Virtual DOM이 왜 있고 무엇으로 이루어져 있는지 짚어봐요.
스트리밍이 켜져 있어도 첫 바이트는 한참 안 와요. 범인은 상위 await 한 줄이에요.
파일 맨 위에 `use client`를 쓰면 경계가 그어지고, 그 아래 모듈까지 전부 클라이언트로 딸려가요.
Card.Body를 평범하게 썼을 뿐인데 App Router에서 에러가 났어요. 범인은 번들러가 못 보는 연결이었습니다.
세 비용을 한 번에 풀 순 없어요. 대신 기본 API와 대안 경로를 같이 둘 수는 있었죠.
느린 것 같으니까 useMemo 감싸자, 로 시작하면 대부분 빗나갑니다.
