덕풀 프로젝트가 성공적으로 끝나면서 리팩토링 해야 할 부분을 지속적으로 찾기 시작했다. 확실히 프로젝트를 실제로 사용하면서 이미지의 레이아웃 시프트, 이미지 리소스 용량 비대와 같은 문제점을 발견했고, 해당 부분을 좀 더 개선시켜야겠다고 생각했다. 홈 페이지를 기준으로 덕질자랑과 덕질토크의 최근 10개 게시물을 불러오도록 하고, 실제 유저에게는 swiper를 사용하여 덕질자랑과 덕질토크 게시물 각각 데스크탑 기준 5개, 4개 모바일 기준 3개, 2개의 이미지만 보여지게된다. 이 때 총 20개의 이미지 리소스를 모두 다운로드 받게되면 페이지 로딩 시간이 길어지는 문제가 발생했다. 이 부분을 Lazy Loading을 통해 성능적으로 많은 개선을 이루어서 해당 포스팅을 통해 소개해보고자 한다. 가장 먼저 이미..
서비스를 구현함에 있어서 에러처리는 굉장히 중요한 부분이다. 실제로 유저들이 서비스를 사용하면서 에러가 발생했을 때 그에 따른 처리를 구현해놓지 않는다면 사용자는 에러로 인한 터진 애플리케이션을 보게되고, 현재 서비스에 어떤 문제가 있는것인지 유저들은 확인할 수 있는 방법이 없다. 따라서 고스란히 서비스에 대한 신뢰성 하락과 유저 이탈로 이어질 수 있다. 여러 프로젝트를 진행하면서 에러처리에 신경을 썼다고 생각했지만, 에러가 발생할 만한 컴포넌트 내에서 에러 처리를 해준다거나 try catch를 남발하는 등,, 지금 돌이켜보면 효과적으로 에러처리를 진행하지는 못한 것 같다. 따라서 덕풀 서비스를 구현하면서 에러처리 중앙화에 대해서 고민했던 상황들을 소개해보고자 한다. 발생 가능한 에러 상황 나는 덕풀 프..
이번 포스팅은 "덕풀" 프로젝트를 진행하면서 애플리케이션 유저 상태와 인증 로직을 관리한 방법에 대해 이야기 해보고자 한다. 모달 전역 관리에 대해서 소개했던 지난 포스팅에서는 뷰와 더 밀접하고, 애플리케이션 전체 뷰 뿐만 아니라 서브 뷰에서도 사용이 용이하기 때문에 Context API를 사용했다고 소개했지만, 유저 상태 및 인증 로직은 애플리케이션 전체에서 단 하나만 존재해야하는 앱 상태 그 자체이고, View의 라이프 사이클과 무관하게 애플리케이션 자체의 라이프 사이클을 따라가는 영속적인 상태이기 때문에 전역관리 라이브러리인 Jotai를 사용하여 구현했다. 일단 위에서 언급했듯이 전역 상태 라이브러리를 통해서 유저 상태와 인증 로직을 관리한 이유에 대해 설명했으니, 들어가기에 앞서 전역 상태 라이브..
오랜만의 포스팅이다! 3달 동안 프로젝트를 진행하느라 포스팅을 미루고 미루다가, 드디어 배포를 끝내고 아껴놨던 포스팅거리들을 풀 시간이 된 것 같다. 이번에는 "덕풀"이라는 덕질 공유 플랫폼 프로젝트를 개발했는데, 혼자서 개발 환경 세팅, 기능 개발, 배포까지 A to Z를 해야하다보니 중간중간 지칠때도 많았던 것 같다. 역시 개발은 여러명이서 함께해야 즐거워,,, 이번에 작성할 블로그 주제는 프로미스를 사용한 전역 모달 관리다. 이전의 프로젝트를 진행하면서도 전역 모달 관리를 사용했고, 관련해서 블로그 포스팅도 썼는데도 불구하고 다시 한 번 같은 주제를 들고왔다. 이전의 전역 모달 관리 방법을 "덕풀" 프로젝트에서도 사용하려고 보니 생각보다 효율적이지 않은 부분이 많다는 것을 알게되었고, 해당 문제점들..
다들 React를 처음 공부할 때 여러가지 훅의 쓰임새와 활용방법등을 공부하면서 useMemo와 useCallback이라는 훅을 접해봤을 것이다. 처음 내가 useMemo와 useCallback을 공부했을 때 사용이유는 다음과 같았다. - useMemo는 계산 비용이 높은 연산의 결과를 기억하고, 의존성 배열에 넣어준 deps가 변경되지 않으면 계산한 값을 재사용한다. - useCallback은 함수를 메모이제이션하고, 의존성 배열에 넣어준 deps가 변경되지 않으면 이전에 생성한 함수를 재사용한다. 두 훅 모두 React를 사용하면서 렌더링 성능 최적화를 위해 사용하는 훅인데, 사실 사용하지 않아도 개발자 경험에는 큰 영향을 주지않는다. 사실 큰 영향을 주지않는다기보다 개인적으로 아직 내 실력과 경험이..
프론트엔드 개발을 공부하다보면 마주칠 수 밖에 없는 개념인 CSR과 SSR등 여러 렌더링 방식이 존재한다. 이 여러 렌더링 방식에 대해서 자세하게 알아보는 포스팅을 준비했다. 그 이전에 SPA(Single Page Application)와 MPA(Multi Page Application)에 대해서도 다뤄보자. 이 포스팅은 나 포함 많은 주니어 개발자가 가지고 있던 잘못된 지식에 대해서도 바로잡을 수 있는 시간이 될 수 있을것 같다. MPA MPA(Multi Page Application)은 전통적인 웹 애플리케이션 방식으로 페이지 당 하나의 html 파일을 갖고, 새로운 페이지 요청 시마다 정적 리소스가 다운로드 되고 전체 페이지를 다시 렌더링하는 방식이다. 간단하게 말하면 HTML 파일이 여러개 있는 ..
이전포스팅에서는 자바스크립트에서 비동기를 처리하는 방식 중 하나인 Promise에 대해서 소개했다. Promise는 Promise가 나온 이전에 사용했던 콜백 함수 패턴의 콜백 지옥을 해결하고 에러처리의 단점을 해소할 수 있었다. 하지만 Promise는 후속처리 메서드 인터페이스에 종속되는 단점이 존재하고 이에 따라 가독성이 떨어져 구현하고자 하는 로직의 의도를 한번에 파악하기 어렵다는 문제가 있다. 이 문제를 해결할 수 있는 문법이 바로 ES2017에 도입된 async/await이다. 그렇다고해서 async/await가 Promise를 대체하는 것은 절대 아니다. async/await는 간단한 문법으로 동기적인 코드처럼 보이는 가독성을 가질 뿐 내부적으로는 Promise를 사용해서 비동기를 처리하고 있..
프로미스 이전의 비동기 작업 단점 1: 콜백 지옥 기존의 자바스크립트에서는 비동기 작업을 처리하기 위해서 콜백 함수를 사용했다. 하지만 콜백 함수를 사용해서 비동기 작업을 처리하는 경우 비동기 작업의 순서를 보장하기 위해 중첩된 콜백 함수를 사용하게되고 이로 인해 코드의 들여 쓰기가 깊어져 가독성이 떨어지는 효과가 나타난다. ( 모양이 아도겐 같다 ) 그런데 콜백 지옥이 발생하는 근본적인 원인은 무엇일까? function foo() { setTimeout(() => { return 1 }, 0); } const result = foo(); console.log(result);// undefined 위의 코드를 보자. 비동기 함수란 함수 내부에 비동기로 동작하는 코드를 포함한 함수를 말한다. foo 함수 ..
