Data Availability First Pattern이란TkDodo의 Status Checks in React Query 글에서 소개된 패턴이다.리액트 쿼리 사용 시 이미 캐시된 쿼리가 있을 때, refetch에서 에러가 발생해도 캐시된 데이터를 계속 보여주는 패턴이다.코드로 보는 편이 빠를 것 같다.일반적으로 리액트 쿼리를 아래와 같이 사용한다.const {data, isPending, error} = useTodos()if (isPending) { return 'Loading...'}if (error) { return 'An error has occurred: ' + error.message}return {data.map(renderTodo)}이 경우 refetch에 실패하는 경우 캐시된 데이..

이 글은 FE에서 유지보수 가능한 e2e 테스트 코드 작성 방법 대해서 다룬다.대상은 playwright의 실행 및 기본적인 문법을 알고있다고 가정한다. FE에서 e2e에 대한 찬반 및 도입 이유찬성유닛, 통합 테스트와 달리백엔드와 연계하여 실제 동작 검증환경 변수, 인증 문제 등을 파악할 수 있음... 반대테스트 실행 시간이 오래 걸림flaky하다 (테스트 코드의 문제가 아니라, 네트워크 타이밍 이슈 등으로 인해서 깨지기 쉽다)유지보수 비용이 큼QA 팀의 하위호환으로 불필요하다고 판단되기도 한다.https://tech.kakaoent.com/front-end/2023/230209-e2e/ 도입 이유먼저 나는 FE에서 e2e가 필수라고 생각하지는 않는다.QA 팀 역할의 하위호환이 맞다고 생각하며,백엔드의..

이 글은 프론트엔드에서 테스트 코드의 필요성에 대해 경험을 바탕으로 정리하였다.먼저 테스트 코드의 장단점에 대해서 간략하게 알아보고,테스트 코드가 없었을 때 얼마나 나쁜 상황이 되는지를 실제 경험을 바탕으로 말해보려한다. 프론트엔드에서 테스트코드가 잘 작성되지 않는 이유- 추가적인 개발 비용 및 일정 압박- UI를 포함하는 높은 테스트 코드 작성 난이도- 백엔드에 비해 상대적으로 장애가 크리티컬하지 않다고 인식됨- 테스팅 도구(vitest, playwright 등), 좋은 품질의 테스트 코드를 위한 학습 비용등등이러한 이유로 테스트 코드는 항상 우선순위에서 밀린다. 그럼에도 테스트 코드의 장점- 리팩토링 안정성 기능 수정이나 추가 시 심리적 안정감을 주고, 테스트 실패 지점으로부터 빠르게 버그를 해결할..

이 글에서는 유저 인증 상태를 어떻게 관리하는지에 대한 고민과 나름의 해결방법에 대해서 다룬다. 리액트 쿼리만 사용했을 경우 발생하는 DX 문제를 살펴보고, 이를 해결하기 위해 Context를 의존성 주입 도구로서 활용하는 방법을 소개한다.또한, 이 접근 방식이 유발할 수 있는 워터폴 요청 문제와 이를 피하기 위한 방법에 대해서도 다룬다. 문제 상황 (DX 관점)예를 들어, 헤더, 대시보드, 프로필 등 여러 컴포넌트에서 유저의 값에 접근해야하는 경우리액트 쿼리만 사용하게 된다면 다음과 같은 코드를 작성해야한다.export function useGetMe() { return useQuery({ queryKey: ["me"], queryFn: () => getMe(), staleTime: ..

이 글에서는 소프트 내비게이션의 LCP(Largest Contentful Paint)를 측정하는 방법에 대해서 다룬다.LCP 측정에는 web-vitals 라이브러리와 측정 자동화 및 반복 시행을 위해 playwright를 사용한다. 들어가기에 앞서웹 성능 지표웹 성능 지표 중 코어 웹 바이탈은 링크에서 자세한 설명을 확인할 수 있다.- 최대 콘텐츠 페인트 (LCP): 로드 성능을 측정합니다. 우수한 사용자 환경을 제공하려면 페이지가 처음 로드되기 시작한 지 2.5초 이내에 LCP가 발생해야 합니다. - 다음 페인트에 대한 상호작용 (INP): 상호작용을 측정합니다. 우수한 사용자 환경을 제공하려면 페이지의 INP가 200밀리초 이하여야 합니다.- 누적 레이아웃 변경 (CLS): 시각적 안정성을 측정합니..

CSS에는 폰트 우선순위만 적혀있을 뿐 현재 어떠한 폰트가 적용되어있는지 알 수가 없다. 크롬 개발자 도구 -> Element -> Computed 에서 폰트패밀리를 클릭하면 아래와 같이 적용된 폰트(Rendered Fonts)를 볼 수 있다.

결론부터말하면 나는 react를 사용하는 개발자의 관점에서는 비동기함수라고 생각한다. 당연히 이렇게 생각하고 있었지만어디선가 setState는 동기함수지만 비동기함수처럼 동작한다. 라는 글을 보고 생각을 남긴다. 이 주장의 근거는 setState 함수는 변경하려는 값을 다른 함수에 위임하고 종료되니 동기함수다. 즉, state 변경을 예약하는 것으로 끝나니 동기함수다.하지만 state값이 즉시 변경되지 않고 react 렌더링 사이클에 따라 state 값이 업데이트 되므로 비동기함수처럼 동작한다. 이 주장이 틀렸다고 생각하지는 않는다.단지 추상화 수준과 관점의 차이라고 생각한다.이 주장은 react 자체를 개발하는 입장에서는 맞다고 생각하나react를 활용하여 개발하는 입장에서는 좋지 못한 주장이라 생각한..

bcrypt 버전: 5.1.1 node-alpine에서 bcrpyt.compare 함수 호출 시 앱이 죽는 문제를 해결한 글 문제상황로컬에서 잘 동작하던 node 서버를 node-apline 이미지에 위에 올려서 실행하니 로그인 요청 시 갑자기 서버가 죽어버렸다.서버 최상위에 try catch와 로그인 관련 함수에도 try catch를 넣어놨는데 서버가 죽었다.심지어 아무런 에러 메시지도 나오지 않았다. 정확히 아래의 부분에서 서버가 죽는다.const match = await bcrypt.compare(pw, user.password); 이러한 문제를 겪는 사람들이 꽤 있나보다.https://github.com/kelektiv/node.bcrypt.js/issues/1006 원인아래 링크를 보면 bcr..