인터렉티브 UI(버튼,링크,인풋 등)에 적절한 tabIndex를 설정하는 것은 UX와 웹 접근성에 유리합니다.저의 문제 상황은 다음과 같습니다.위와 같이 퀴즈 페이지가 있습니다.마우스를 사용하지 못하여, tab을 통해 인터렉티브 UI에 focusing을 잡으려 합니다.

Lighthouse로 접근성을 측정하면 아래와 같이 직접 확인을 해야할 목록들을 보여줍니다.그중에서 위에서 펼쳐진 부분에 대해서 멈칫했는데요.모달 같은 컨텐츠가 있을시, 유저가 포커스할 때, 모달 내부 인터렉션이 포커스가 되어야한다고 말해주고 있습니다.이제 저의 문제

이번에는 웹 접근성 관련한 리팩토링을 진행해볼까합니다. 웹 접근성 향상을 위해서는 aria 속성을 태그에 적절히 활용할 수 있는데요. ARIA(Accessible Rich Internet Applications) 속성은 웹 접근성을 개선하기 위해 HTML 요소에 추가

위 컨텐츠는 서버에서 받아온 HTML을 통해 보여주고 있습니다.서버에서 받아온 위와 같은 HTML을 보여주기 위해서는 다음과 같이 dangerouslySetInnerHTML 속성을 사용합니다.dangerouslySetInnerHTMLdangerouslySetInnerH

이번에는 URL path를 상수로 변경하는 작업을 해보려합니다.기존에는 다음과 같이 직접 문자를 입력하는 식으로 관리하였습니다.하지만 위와 같이 관리한다면 특정 URL path를 변경한다면 해당 path를 사용하는 모든 파일을 일일히 찾아서 변경해줘야합니다.예를 들어,

이번에는 프로젝트 전체 컴포넌트들에 시맨틱 태그들이 적절히 적용되었나 점검하고 필요한 부분은 적절한 시맨틱 태그로 변경해보겠습니다.semantic은 의미론적인이라는 뜻을 가지고 있습니다.프로그래밍에서, 시맨틱은 코드 조각의 '의미'를 나타냅니다.그렇다면 시맨틱 태그란

프로젝트에서 퀴즈 도메인 관련 비즈니스 로직을 응집도있게 관리하기 위해 다음과 같이 class로 관리하였습니다.함수로 관리하지 않은 이유는 각 메서드들이 서로 연관성이 있게 사용되고 있기 때문에 class로 관리하여 서로 참조하여 사용하게 하였습니다.위 클래스는 Qui

이번에는 LCP 관련하여 살펴보겠습니다.LCP는 최대 텍스트 또는 이미지가 표시되는 시간입니다.측정 기준으로써는 2.5초 이내로 측정되어야 빠르다고 분류되네요.Lighthouse 측정 결과,측정 페이지의 LCP는 위와 같이 h1 태그로 큼지막히 적힌 텍스트였습니다.저의

이번에는 Lighthouse 또 다른 진단항목 HTTP/2 사용 권장을 살펴보겠습니다.기존에는 모든 정적 파일들에 대한 통신은 HTTP/1.1로 하고 있습니다요청/응답 방식클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 보내는 구조.한 연결당

이전에는 Lighthouse 측정 중 진당 항목에서 렌더링 차단 리소스 부분을 알아보고 제거해봤습니다.오늘은 또 다른 진단항목인 사용하지 않는 자바스크립트 줄이기 항목에 대해 알아보겠습니다.위 진단 항목에서 지정한 스크립트 \_next/static/chunks/517-

퀴즈 프로젝트를 일단락 마무리하여 이제 성능 최적화 작업을 해보려합니다. 여태까지 성능최적화 작업을 해보지 않아 무엇부터 해야할지 갈피를 잡지 못했는데요. 할 수 있는 작업들이 여러가지 있지만 우선 크롬 개발자 도구 Lighthouse와 Performane를 사용하

이번 리팩토링에서는 a 태그와 button 태그에 대해 다뤄보려고 합니다.a 태그와 button 태그가 의도에 맞게 사용되도록 리팩토링을 진행해보려합니다.이전 코드에서는 두 태그를 중첩하여 사용하거나 의도에 맞게 사용하지 않고 있었습니다.바로 코드로 살펴보겠습니다.ne

페이지 컴포넌트를 클라이언트 컴포넌트와 서버 컴포넌트로 선언했을 때의 차이를 알아보려하는데요.특정 페이지를 클라이언트 컴포넌트와 서버 컴포넌트로 선언했을 때, 클라이언트 자바스크립트 번들 크기가 얼마나 차이가 나는지 확인해보겠습니다.클라이언트 자바스크립트 번들 크기가

프로젝트 기능 개발이 끝나 리팩토링을 진행해보려합니다.처음에는 무엇부터 시작을 해야하나.. 막막했지만 코드를 한참 들여다보니 할 수 있는 부분들이 보입니다.리팩토링을 하기에 앞서, 목적이 먼저 있어야할텐데요.저는 최적화와 가독성 및 유지보수에 두었습니다.최적화가독성 및

프로젝트를 진행하다보면 클라이언트에서 백엔드 API로 data mutation(HTTP POST,PATCH,PUT,DELETE)를 할 일이 발생합니다.하지만 nextjs에서는 위 방법으로써 Server Action 기능을 제안하고 있는데요.Server Action을 굳

퀴즈 프로젝트를 진행하는데 퀴즈 페이지들을 SSG 방식으로 빌드타임 때,만들어주고 있었습니다.퀴즈 데이터를 하루마다 수정하고 있어 수정할 때마다 즉, 하루마다 배포를 진행해줘야하는데요.이 과정이 꽤나 귀찮다고 느껴졌습니다.그러던 찰나에 ISR이라는 것이 생각나 적용해보

nextjs 문서의 server component 관련 내용을 살펴보다 더 자세히 이해하고 싶은 부분ㅇ이 있었습니다.살펴보던 중,Server Component의 장점(https://nextjs.org/docs/app/building-your-applicatio

Nextjs의 Data Cache 결론부터 말하자면 nextjs의 Data Cache의 기능으로 캐싱된 데이터를 계속 불러오기 때문입니다. 상황 및 원인 분석 퀴즈 관련 프로젝트를 진행하고 있습니다. ![](ht

Nextjs의 Server Component에 대해 공부하는 중, RSC(React Server Component)가 어떻게 렌더링되는가(https://nextjs-ko.org/docs/app/building-your-application/rendering/s

프로젝트를 진행하다 퀴즈라는 특정 도메인 전체에서 클라이언트 비즈니스 로직을 사용하고자하는 경우가 생겼습니다.여기서 말하는 클라이언트 비즈니스 로직이란 클라이언트 컴포넌트에서 사용할 비즈니스 로직을 말합니다.프로젝트에서 퀴즈 풀기 관련 도메인이 있는데요. 저는 응집도