🤨 뒤로가기를 눌렀는데 홈 화면으로 간다고? 내가 만들고 있던 서비스에는 온보딩 프로세스가 있었다. 해당 온보딩 플로우는 아래와 같이 여러 단계를 거치는 구조였다. 모임을 선택하거나 새로 생성하고 기능을 선택한 후 본격적인 사용으로 진입 기존의 경우, 모든 화면은 하나의 URL(PATH.ONBOARDING)에서 렌더링되고 있었으며 각 단계가 React 상태로 관리되고 있었다. 하지만 여기서 브라우저의 뒤로가기 버튼을 눌렀을 때 문제가 발생했다. 사용자가 기능 선택 화면에서 “뒤로 가기” 버튼을 누르면, 이전 단계인 모임 선택 화면으로 가야 할 것으로 예상했지만, 실제로는 온보딩 페이지를 클릭하기 전 경로로 이동했다. 그 이유는 다음 또는 이전 버튼을 클릭할때 페이지가 이동하는 것이 아닌 를 저장하고 있는 상태가 변하였고 이에 따라 브라우저 히스토리에 아무 변화도 없었기 때문이었다. 따라서 뒤로가기 버튼을 누르면 이전 단계가 아닌 온보딩 페이지를 클릭하기 전 경로로 이동했던 것이다…

검색 기능을 구현하다 보면 자주 마주치게 되는 문제들이 있다. 특히 사용자 입력에 따라 자동완성 기능을 제공할 때는, 작은 입력 하나하나가 API 호출로 이어지면서 성능과 UX를 크게 해칠 수 있다. 이번 글에서는 카카오 주소 검색 기능을 구현하는 과정에서 디바운스를 통해 불필요한 API 호출을 줄인 경험을 공유해보려고 한다. 🧩 디바운스란? 디바운스란 무엇일까? 는 사용자가 짧은 시간 간격으로 연속적인 이벤트를 발생시킬 때, 마지막 이벤트 이후 일정 시간 동안 추가 이벤트가 발생하지 않으면 그제서야 지정된 작업(API 호출 등)을 한 번만 수행하도록 하는 기법이다. 이로 인해 이벤트가 과도하게 발생해도, 실제 작업은 필요한 경우에만 한 번 실행되어 리소스를 효율적으로 사용할 수 있다. 디바운스와 함께 따라오는 개념으로는 쓰로틀이 있다. 은 디바운스와 유사하게 이벤트의 빈도를 제어하는 기법이지만, 동작 방식에는 차이가 있다. 디바운스가 마지막 이벤트 이후 일정 시간이 지나야 작업을…

🎯 자바스크립트는 언어이다. 자바스크립트는 싱글 스레드 언어로, 한 번에 하나의 작업만 처리할 수 있다. (이러한 특성 때문에 자바스크립트는 자바나 C++처럼 여러 스레드를 병렬로 활용하는 멀티스레드 언어와는 다른 방식으로 동시성을 처리하게 된다.) 그렇다면 자바스크립트로는 동시에 여러 작업을 할 수 없는 것일까? 그렇지 않다! 자바스크립트는 네트워크 요청, 타이머, 사용자 입력 등 다양한 비동기 작업들을 마치 동시에 실행되는 것처럼 효율적으로 처리할 수 있는데, 이 모든 동작의 중심에는 바로 라는 메커니즘이 있다. 🔁 이벤트 루프? 자바스크립트는 기본적으로 메인 스레드에서 실행되며, 이 메인 스레드는 아래의 영역들로 나뉘어 동작한다. 📦 콜 스택 함수 호출이 일어나는 공간으로, 동기적 코드가 실행되는 구조이다. 함수가 호출되면 스택에 쌓이고, 실행이 끝나면 스택에서 제거된다. 📦 Web API 브라우저나 Node.js가 제공하는 기능 영역으로, setTimeout, fet…

나는 react-hook-form 라이브러리를 통해 폼을 관리하고 있다. 라이브러리를 사용할때는 왜 해당 라이브러리를 선택했는지? 꼭 해당 라이브러리를 선택해야만 했는지? 등에 대해 고민해보고 사용해야한다고 생각한다. 이번 포스팅에서는 왜 react-hook-form 라이브러리를 사용했는지에 대해 설명해보고자 한다. 그 전에 먼저 제어, 비제어 컴포넌트에 대해 알아보자. 👉🏻 제어 컴포넌트 공식문서에서는 를 아래와 같이 설명하고 있다. 위의 설명을 정리해보면 란 DOM이 아닌 React State로 사용자의 입력을 관리하는 컴포넌트라고 할 수 있다. 아래의 코드를 통해서 조금 더 알아보자 위 코드는 input 요소에 사용자가 타이핑할 때마다 onChange 이벤트가 발생하고, 입력값이 상태로 저장된다. 이렇듯 에서는 입력값의 변경이 곧바로 상태에 반영되므로 사용자가 입력한 값(화면에 보여지는 값)과 실제 데이터로 저장된 값이 항상 일치한다는 특징이 있다. 하지만 이러한 특징 때문에 …

프로토타입 기반 객체지향 언어인 JavaScript에 대해 알아가던 중 this 바인딩을 알게되었다. 그리고… 머리가 너무 아파졌다… 너무 어려웠기 때문이다. 그래서 이번 기회에 this 바인딩에 대해 알아보고 정리해보려고 한다. (참고로 this라는 키워드는 자바스크립트에서 뿐만아니라 Java, C#등의 객체지향 프로그래밍 언어에서 사용된다.) JavaScript에서 this는 함수가 호출되는 방식에 따라 다르게 바인딩된다. 생각났다 이것땜에 머리가 어지러웠다. 그래도 다시 호흡하며… 에 따라 this에 바인딩되는 객체가 달라진다고 하는데 그렇다면 함수가 호출되는 방식에는 어떠한 것이 있을까? 은 아래와 같이 다양하다. 일반 함수 호출 메서드 호출 생성자 함수 호출 apply/call/bind 호출 위의 함수 호출방식에 대해 하나씩 알아보자. 1️⃣ 일반 함수 호출 위 코드의 실행결과를 보면 알 수 있듯이 로 호출될 때 this는 를 가리킨다. (즉, 브라우저에서는 window…

mdn에 따르면 JavaScript 호이스팅은 인터프리터가 코드를 실행하기 전에 함수, 변수, 클래스 또는 임포트(import)의 선언문을 해당 범위의 맨 위로 끌어올리는 것처럼 보이는 현상을 말한다. 이는 변수나 함수가 실제 코드에서 작성된 위치와 관계없이 선언 단계에서 메모리에 저장되기 때문에 발생한다. 이러한 호이스팅은 var,let,const에서 모두 이루어진다. (var, let, const는 자바스크립트에서 변수를 선언할 때 사용하는 키워드이다.) var var은 다음과 같은 특징을 가진다. 함수 스코프 재선언 및 재할당 가능 호이스팅 발생 아래는 를 가지는 var의 예시이다. var 키워드는 함수 스코프를 가지기 때문에 main 함수 내에서 선언된 변수 a는 함수 스코프 내에서 선언되어 함수 내에서 어디서든 접근할 수 있다. var 키워드는 재선언이 가능하다. 위와 같이 변수 a를 두 번 선언해도 에러가 발생하지 않는다. var 키워드는 호이스팅이 발생한다. 위 코드의…

지금까지 프로젝트를 하면서 react-query를 통해 서버 상태를 관리하곤 했다. react-query를 사용한 이유는 데이터 캐시와 서버 상태를 선언적으로 사용하기 위해서였다. 하지만 처음부터 react-query를 사용한 것은 아니다. 개발과정에서 data-fetching작업이 있었는데 이럴때마다 반복되는 코드를 작성해야했고 이러한 불편함을 개선하기 위해 찾아보던 중 알게되었다. 기존의 data-fetching 작업은 아래와 같이 진행해주었다. 아마 뭐가 불편하다는 거지? 라고 생각하는 사람도 있을 것이다. 하지만 데이터 요청이 늘어난다면 어떻게 될까? 또, 데이터 요청이 서로 연관되어 있다면 어떻게 될까? (즉 A라는 데이터 요청은 B데이터 요청으로부터 응답받은 데이터에 따라 진행될수도 안될수도 있음) 데이터 요청이 늘어난다면 useState를 통해 데이터, 데이터에 대한 에러 상태, 로딩 상태를 관리하는 코드가 반복적으로 작성되어야 한다. 또한 데이터 요청이 서로 연관되어…

프론트엔드 개발을 하면서 한번 쯤은 아래와 같은 에러 화면을 본 적이 있을 것이다. 개발자인 나의 입장에서 개발 과정중에 해당 화면을 보게될 경우 “어? 에러화면이네, 이와 관련된 파일을 찾아 해결해야겠다” 라고 생각할 것이다. 하지만 만약 배포된 사이트에서 일반 사용자가 위와 같은 에러 화면을 보게된다면 어떨까? 개발자가 아닌 일반 사용자가 위 에러 화면을 본다면 “이게 뭐지?” 싶을 것이다. 최악의 경우에는 해당 화면을 보고 사이트를 떠날 수도 있을 것 같다. 따라서 올바른 에러 처리는 개발자 경험(DX) 뿐만 아니라 좋은 사용자 경험(UX)을 위해 중요하다. 그렇다면 에러는 언제 많이 발생할까? 개발 과정에서 에러가 발생하는 상황은 다양하지만 가장 흔하게 발생하는 상황은 아무래도 비동기 호출을 진행할 때인 것 같다. 기존의 경우, 비동기 호출을 진행할때에 try, catch를 이용하여 코드를 짜주었다. 하지만 이 과정에서 다음과 같은 불편함이 있었다. 새로운 에러가 추가될때마…

평소처럼 velog의 트렌딩 글 목록들을 보던 중, React의 useState와 관련된 글을 보았다. 해당 글에서는 ReactHooks, ReactFiberHooks 등의 코드를 통해 useState의 내부 동작을 설명하고 있었으며 useState가 클로저로 구현되어 있음을 설명하고 있었다. 나는 이 글을 보며 useState를 사용하며 코드를 짰던 지난 과정이 부끄러워 졌다. 그 이유는 closure의 개념이 useState에 어떻게 적용되어 있는지도 모른채 useState를 사용하고 있었기 때문이다. (내가 작성한 코드에 대해 나도 잘 모르고, 이에 대해 설명할 수 없다는 것은 정말 부끄러운 일인 것 같다 ㅠㅠ) 따라서 이를 계기로 JavaScript에 대해서 딥다이브 해보는 시간을 가져보고자 했다. 이 글은 나를 JavaScript 딥다이브의 계기로 이끌어준 첫 번째 글로 에 대해 나름대로 찾아보고 정리해보았다. closure란? MDN에서는 클로저를 다음과 같이 설명하고 …

프로젝트의 상태관리 라이브러리를 정하기에 앞서 상태관리란 왜 필요한 것이고, 어떠한 상태관리 라이브러리들이 있는지, 해당 라이브러리의 장단점에는 어떠한 것이 있는지 등에 대해 알아보고 지금 진행하는 프로젝트에는 어떠한 특성을 가진 라이브러리가 적합할지 알아보고자 상태관리에 대해 조금더 자세하게 공부해보았다! (물론 상태관리가 딱히 필요없는 프로젝트도 존재할 수 있다! 따라서 해당 프로젝트가 상태관리가 필요한지에 대해 생각해보는 것도 중요한것 같다!) 🧐 상태관리가 필요한 이유? 먼저 근본적으로 상태관리가 왜 필요한지에 대해 알아보자! 프런트엔드 개발자라면 한번쯤 들어보거나 사용해봤을 라이브러리로는 리액트가 있다. 나 역시 리액트 라이브러리를 사용하여 프로젝트를 진행중이다. 리액트 라이브러리가 뷰나 앵귤러와 비교했을 때 가장 큰 차이점은 단방향 바인딩이라고 할 수 있다. 리액트는 단방향 바인딩을 지원하기 때문에 부모에서 자식으로만 state를 props로 전달할 수 있고, 자식의 p…

오늘은 웹 개발을 해봤다면, 한번 쯤은 마주쳐봤을 CORS에러에 대해 이야기를 해보려고한다. 그렇다면 CORS에러는 왜 발생하고, CORS에러가 발생했을 경우에는 어떻게 해결해 주어야 할까? 👉🏻 Same-Origin-Policy(SOP) & Cross-Origin-Policy(COP) CORS에러에 대해 알아보기 전에 Same-Origin과 Cross-Origin에 대해서 알아보자! 먼저 **“Same-Origin”**이란, 웹 브라우저에서 같은 출처(origin)에서 로드된 문서나 스크립트가 동일한 출처에만 접근할 수 있는 보안 정책을 의미한다. 여기서 **“출처”(Origin)**는 프로토콜, 호스트, 그리고 포트를 포함한 세 가지 요소로 정의된다. 즉, 두 URL이 동일한 프로토콜, 호스트, 그리고 포트를 공유하면 같은 출처로 간주된다. 다음으로 **“Cross-Origin”**이란, 웹 브라우저에서 한 출처(origin)에서 로드된 문서나 스크립트가 다른 출처의 리소스에 접…

syncspot 서비스를 개발하면서 AWS의 S3+CloudFront+Route53을 사용하여 프론트엔드 배포를 진행해주었다. netlify나 vercel을 통한 배포도 가능하지만, 이번 기회에 전체적인 배포 프로세스가 어떻게 이루어지는 지 알아보고 싶기도 했고, Devops에 대한 지식도 쌓을 겸 공부도 하면서 배포를 해보았다. 왜 EC2가 아닌 S3 + CloudFront + Route53를 선택했을까? 우리가 만들고 있는 syncspot 프로젝트의 경우, React로 만든 CSR 프로젝트 이다. React 애플리케이션의 경우 빌드 과정에서 정적 파일(HTML, CSS, JS)로 변환되며, 이러한 정적 파일 배포에는 EC2와 같은 동적 서버보다 S3 + CloudFront + Route 53 조합이 더 적합하다고 판단했다. 그 이유는 S3는 정적 파일을 저렴하고 안정적으로 저장 및 제공할 수 있으며, CloudFront는 글로벌 CDN을 통해 사용자에게 빠르고 안정적인 콘텐츠 …

평소 개발을 하면서 에 대해 많은 고민을 하는 것 같다. 사람마다 에 대한 기준은 다를 수 있겠지만 내가 생각하는 좋은 코드란 변화에 대응을 잘 하는 코드라고 생각한다. 즉 어떠한 기능에 대해 수정 요청이 있을 때 “어, 이 기능이 추가되면 모든 코드를 갈아 엎어야 할 것 같아요.” 라고 답변을 하게 된다면 해당 코드는 좋지 못한 코드라고 생각한다. 그렇다면 왜 변화에 잘 대응하는 코드가 좋은 코드일까? 그 이유는 사용자의 요구사항은 끊임없이 변화하기 때문이다. 아래는 내가 syncspot 프로젝트를 개발하면서 기획자로부터 받은 요구사항 중 일부이다. 장소 입력 기능에서 입력 부분 아래 추천 검색 목록도 볼 수 있도록 변경해주세요. 모바일에서는 지도를 더 크게 보여주고, 장소 목록은 스와이프로 볼 수 있게 해주세요. 첫 번째 요구사항에서 만약 장소를 입력하는 코드가 컴포넌트로 분리되어 있지 않고 하나의 파일내에 함수로 관리되고 있다면 어떻게 될까? 또는 장소를 입력하는 컴포넌트가…

TailwindCSS 어떻게 하면 더 잘 사용할 수 있을까? 해당 글은 tailwindcss를 사용하여 프로젝트를 진행하던 중 느꼈던 불편함과 해결 방법에 대해 정리한 글입니다. syncspot프로젝트 에서 tailwindcss를 사용하여 스타일링을 진행했습니다. 개발을 완료한 후 최종 서비스 출시를 앞두고 디자이너분과 함께 서비스의 전반적인 디자인을 수정하는 작업을 진행하였습니다. 이 과정에서 추가적인 디자인 수정 요청에 의해 특정 페이지의 몇몇 컴포넌트 (button, input 등)에 대한 디자인을 변경하는 과정이 있었습니다. (ex. 회원가입 페이지에서 버튼 색상 변경 등) 문제는 여기서 발생했습니다. 디자이너분의 요청 사항에 따라 특정 페이지에서 사용되는 button, input 등의 디자인을 변경해야 하는 경우가 있었는데 이 경우마다 해당하는 파일의 코드를 찾아 직접 수정해야 했습니다. (즉 수정이 필요한 파일에 찾아가 직접 코드를 하나하나 수정해야 했습니다.) 많은 …