Zustand를 쓰다 보면 이런 경험, 한 번쯤 해보셨을 거예요 👇const count = useStore((s) => s.count);const inc = useStore((s) => s.inc);const handleClick = () => { inc(); console.log(count); // ??? 여전히 이전 값};setter(set)로 값을 바꿨는데 콘솔에 찍으면 갱신이 안 되어있다?Zustand 버그일까요?아니요 --- 이건 React 구조상 당연한 동작이에요.🧩 React와 Zustand의 타이밍 차이React는 "렌더링 단위"로 상태를 관리합니다.컴포넌트는 렌더 시점의 상태 스냅샷을 들고 있고,그 이후 값이 바뀌어도 "다음 렌더" 때까지는 이전 상태를 유지해요.Zustand는 상..
상태관리 라이브러리 Zustand를 쓰다 보면, 여러 상태를 한꺼번에 구독할 때 리렌더링이 생각보다 자주 일어나는 문제를 겪게 된다. 특히 객체를 반환하는 셀렉터(selector)를 쓸 때 그렇다.이 글에서는 그 원인과, useShallow를 어떻게 활용하면 좋은지, 그리고 왜 원시값 중심으로 상태를 설계해야 복잡도가 줄어드는지 정리해본다.🧩 Zustand의 기본 구독 구조보통 우리는 Zustand에서 이렇게 상태를 꺼내 쓴다.const count = useStore((s) => s.count);이 경우 count 값이 바뀔 때만 컴포넌트가 리렌더링된다. 간단하다.그런데 아래처럼 객체 형태로 여러 값을 묶어서 반환하면 이야기가 달라진다.const { count, user } = useStore((s) ..
대규모 Next.js 프로젝트에서 components/**/index.ts 같은 배럴(Barrel) 파일은 거의 반사적으로 등장합니다. 임포트를 깔끔하게 만들고 폴더의 Public API를 정리할 수 있기 때문이죠. 다만 배럴을 과하게 쓰면 번들 최적화(트리 셰이킹)나 유지보수 측면에서 발목을 잡기도 합니다. 이 글은 한국 실무 기준으로 “언제 배럴을 쓰고, 어디서 멈춰야 하는지”를 정리한 가이드입니다.TL;DR (요약)배럴은 ‘도메인 상위 1단’까지만 두고, 더 하위 폴더는 직접 import가 기본.경로 문제는 배럴 남발 대신 @/ 경로 별칭으로 해결.export type { ... } 타입 재수출은 안전(런타임 번들에 미포함).export * 와일드카드 재수출은 최소화. 필요한 것만 명시적으로 exp..
CSRF크로스 사이트 리퀘스트 포저리(교차 사이트 요청 위조)사이트에 로그인된 유저를 대상으로그 사이트에서 API 호출을 몰래 요청하게 만든다.결제 사이트의 결제 요청 API를 분석해본 다음이미지를 포함한 그럴듯한 메일을 보낸다.이미지 주소를 "그 결제 사이트의 결제 요청 API를 호출주소"로 하면유저가 로그인 되어있었다면 모르게 호출이 되고돈이 빠져나가는 상황이 발생함.POST 방식이라고 해도메일에 그럴듯한 Form을 구성하고버튼을 누르게 만들면 같은 원리로 빠진다.쿠키 SameSite=Strict로 해두면 같은 도메인의 웹사이트에서만 API가 호출된다. 만약 SameSite=Strict가 제한된다면 CSRF 전용 토큰을 활용한다는 등 해야한다
PWA는 'Progressive Web Apps'의 줄임말로 모바일 웹을 어플처럼 쓸 수 있게 도와주는 표준기술.1. nuxt 3 > integrations > modules > 'PWA' 검색2. 문서에 따라 차분히 진행https://vite-pwa-org.netlify.app/frameworks/nuxt.html npx nuxi@latest module add @vite-pwa/nuxtexport default defineNuxtConfig({ modules: ['@vite-pwa/nuxt'], pwa: { /* your pwa options */ }})3. 헤더에 아래와 같이 pwa 수동설치 가능한 버튼 생성 앱 설치4. 근데 왜 안 먹히지? node_modules 까보면 알겠지5...
