덕풀 프로젝트가 성공적으로 끝나면서 리팩토링 해야 할 부분을 지속적으로 찾기 시작했다. 확실히 프로젝트를 실제로 사용하면서 이미지의 레이아웃 시프트, 이미지 리소스 용량 비대와 같은 문제점을 발견했고, 해당 부분을 좀 더 개선시켜야겠다고 생각했다. 홈 페이지를 기준으로 덕질자랑과 덕질토크의 최근 10개 게시물을 불러오도록 하고, 실제 유저에게는 swiper를 사용하여 덕질자랑과 덕질토크 게시물 각각 데스크탑 기준 5개, 4개 모바일 기준 3개, 2개의 이미지만 보여지게된다. 이 때 총 20개의 이미지 리소스를 모두 다운로드 받게되면 페이지 로딩 시간이 길어지는 문제가 발생했다. 이 부분을 Lazy Loading을 통해 성능적으로 많은 개선을 이루어서 해당 포스팅을 통해 소개해보고자 한다. 가장 먼저 이미..
서비스를 구현함에 있어서 에러처리는 굉장히 중요한 부분이다. 실제로 유저들이 서비스를 사용하면서 에러가 발생했을 때 그에 따른 처리를 구현해놓지 않는다면 사용자는 에러로 인한 터진 애플리케이션을 보게되고, 현재 서비스에 어떤 문제가 있는것인지 유저들은 확인할 수 있는 방법이 없다. 따라서 고스란히 서비스에 대한 신뢰성 하락과 유저 이탈로 이어질 수 있다. 여러 프로젝트를 진행하면서 에러처리에 신경을 썼다고 생각했지만, 에러가 발생할 만한 컴포넌트 내에서 에러 처리를 해준다거나 try catch를 남발하는 등,, 지금 돌이켜보면 효과적으로 에러처리를 진행하지는 못한 것 같다. 따라서 덕풀 서비스를 구현하면서 에러처리 중앙화에 대해서 고민했던 상황들을 소개해보고자 한다. 발생 가능한 에러 상황 나는 덕풀 프..
이번 포스팅은 "덕풀" 프로젝트를 진행하면서 애플리케이션 유저 상태와 인증 로직을 관리한 방법에 대해 이야기 해보고자 한다. 모달 전역 관리에 대해서 소개했던 지난 포스팅에서는 뷰와 더 밀접하고, 애플리케이션 전체 뷰 뿐만 아니라 서브 뷰에서도 사용이 용이하기 때문에 Context API를 사용했다고 소개했지만, 유저 상태 및 인증 로직은 애플리케이션 전체에서 단 하나만 존재해야하는 앱 상태 그 자체이고, View의 라이프 사이클과 무관하게 애플리케이션 자체의 라이프 사이클을 따라가는 영속적인 상태이기 때문에 전역관리 라이브러리인 Jotai를 사용하여 구현했다. 일단 위에서 언급했듯이 전역 상태 라이브러리를 통해서 유저 상태와 인증 로직을 관리한 이유에 대해 설명했으니, 들어가기에 앞서 전역 상태 라이브..
오랜만의 포스팅이다! 3달 동안 프로젝트를 진행하느라 포스팅을 미루고 미루다가, 드디어 배포를 끝내고 아껴놨던 포스팅거리들을 풀 시간이 된 것 같다. 이번에는 "덕풀"이라는 덕질 공유 플랫폼 프로젝트를 개발했는데, 혼자서 개발 환경 세팅, 기능 개발, 배포까지 A to Z를 해야하다보니 중간중간 지칠때도 많았던 것 같다. 역시 개발은 여러명이서 함께해야 즐거워,,, 이번에 작성할 블로그 주제는 프로미스를 사용한 전역 모달 관리다. 이전의 프로젝트를 진행하면서도 전역 모달 관리를 사용했고, 관련해서 블로그 포스팅도 썼는데도 불구하고 다시 한 번 같은 주제를 들고왔다. 이전의 전역 모달 관리 방법을 "덕풀" 프로젝트에서도 사용하려고 보니 생각보다 효율적이지 않은 부분이 많다는 것을 알게되었고, 해당 문제점들..
이번 포스팅은 진행중인 프로젝트의 핵심 기능들의 개발이 끝나면서, 프로젝트를 출시하게 됐을 경우 많은 사용자들이 알 수 있게 검색 엔진에 노출될 수 있도록 하는 과정은 필수적이기 때문에, 해당 프로젝트의 SEO를 최적화하는 과정에 대해서 소개하려고 한다. SEO란? 해당 웹사이트가 구글, 네이버, 다음과 같은 검색 엔진에서 높은 순위를 차지하여 잘 노출될 수 있도록 최적화 하는 프로세스 검색 엔진은 사용자의 특정 키워드 검색을 결과로 반환하는데, 이 때, 웹 사이트를 검색 엔진에게 더 잘 이해시키고 노출시키는 방법 head 태그 일반적으로 html 파일 내의 ); } next/head 서버 측에서 실행되는 _document.tsx 파일에서는 애플리케이션의 공통적인 html 구조를 정의하면서 next/do..
폴더 구조 수정과 리팩토링이 조금 남아있지만 이제 네컷지도 프로젝트가 막바지로 향해가고 있다. 기본적인 핵심 기능들은 구현이 완료되었고, 이번에는 FAQ 페이지를 구현하면서 문의할 사항들을 프로젝트 측에 유저가 전달할 수 있도록 이메일 링크를 걸어주는 작업을 하면서 몇가지 헷갈렸던 사항들을 정리하고자 한다. Nextjs의 Link 컴포넌트의 내용과 함께! Link 컴포넌트 일단 Nextjs의 Link 컴포넌트에 대해서 살펴보자. Nextjs는 pages 폴더내에서 애플리케이션의 라우팅이 구성되고, Nextjs의 Link 컴포넌트는 페이지 전환을 위한 컴포넌트로 클라이언트 측에서 페이지를 전환하기 때문에, 새로고침이 일어나지 않는다. Link 컴포넌트의 대표적인 props는 다음과 같다. Link 컴포넌트..
저번 포스팅에는 recoil을 설치하고, nextjs에서 세팅하는 방법과 기본적인 recoil의 사용법에 대해 포스팅을 진행했다. 해당 포스팅을 하면서 recoil을 통해 애플리케이션의 모달 상태를 전역으로 관리하는 방법에 대해서 포스팅을 진행할 것이라고 언급했는데, 이 포스팅에서 한 번 소개해보도록 하겠다. 현재 진행중인 프로젝트는, 로그인 유저와 비로그인 유저에 따라서 처리해야할 로직이 존재한다. 로그인 유저는 애플리케이션의 모든 기능에 접근이 가능하지만, 비로그인 유저에 한해서는 특정 기능에서, 로그인이 필요하다는 모달을 띄워줘야만 했다. recoil을 통해 모달의 상태를 전역관리 하기 이전에는, 각 페이지에서 작성한 모달 컴포넌트와 모달의 상태 함수인 setState 함수를 관련 컴포넌트에 pro..
현재 진행중인 프로젝트는 비로그인 상태의 유저도 애플리케이션을 이용할 수 있도록 설계되었는데, 특정 페이지는 로그인한 유저만 접근하도록 비로그인 유저에 한해서 페이지 접근 제한을 구현해야 했다. 해당 로직을 구현하면서 어려움을 겪었던 과정과 채택하게 된 로직에 대해서 포스팅을 진행해보고자 한다. 1. axios interceptor 가장 처음엔, 비로그인 유저를 접근 제한해야 하는 페이지 내에서는 페이지 접속 시 api를 통해 유저의 정보를 가져오도록 되어있어서, 해당 axios interceptor에서 로직을 구현하려 했다. 기본적으로 api 요청시 헤더에 토큰을 담아 요청하기 때문에, 비로그인 유저로 해당 페이지에 접속하게 되면 401 에러를 만나고, interceptor 내에서 해당 에러를 만났을 ..
