분류 전체보기

웹서비스는 존재하지 않는 URL로 접근할때 대체 페이지를 보여줘야한다. 웹 서버가 요청된 리소스를 찾지 못했음(Not Found)을 나타내는 HTTP 상태 코드인 404를 이용해 404페이지라고 부르기도한다. react-router-dom은 Router 컴포넌트에서 페이지를 관리하는데, 각 경로에 맞는 페이지 컴포넌트를 조건부 렌더링하는 식이다. 나머지 모든 경로(*)에 404페이지를 보여주면 간단히 목적을 달성할 수 있다. 왜 404페이지에 오게 되었는지 그 원인을 알려주면 더 사용자 친화적인 서비스를 만들 수 있다. 더하여 상황에 맞게 "홈으로 이동" 같은 버튼도 추가해주면 사용자가 서비스를 편하게 이어서 즐길 수 있고 원하지 않는 사용자 이탈도 줄일 수 있을 것이다.

1. 분석 이유 Modal이나 BottomSheet같은 Overlay는 브라우저에서 굉장히 자주쓰이는 컴포넌트이다. 나는 Overlay를 잘 사용하고 싶어 더 나은 사용 방법을 분석하고 앞으로 프로그래밍에 사용하고자한다. 2. 이전 Modal 로직 작성 방식 이전 프로젝트를 진행할때 사용했던 모달 열고 닫기 로직이다. 모달을 사용하는 App에서 isModalOpen 상태를 선언해서 Modal 을 조건부 렌더링한다. function App() { const [isModalOpen, setIsModalOpen] = useState(false); ... const handleRestaurantClick = (e: React.MouseEvent) => { ... setIsModalOpen(true); }; co..

1. 작성 계기 LocalStroage 값을 get, set 할 수 있는 훅을 만들었다. 만들면서 고려한 부분은 다음과 같다. LocalStroage 값을 변경했을 때 같은 LocalStroage를 바라보는 컴포넌트들도 동기화되어야 한다. 같은 탭이 아닌 다른 탭에서도 1번이 적용되어야 한다. 2. 로직 작성 기본적으로 LocalStorage는 Web API이기 때문에 useEffect에서 호출하여야 한다. 눈여겨볼 부분은 다음과 같다. window 환경에서만 동작하도록 가드: L16~18, L36~38 WindowEventMap 타입에 "local-storage" 커스텀 이벤트 타입 추가: L4~8 storage, local-storage 이벤트 발생 시 동기화를 위해 updateStorageChang..

1. 문제 상황 현재 동글은 스토리북을 로컬에서만 사용 중이다. 동글의 스토리북을 chromatic으로 쉽게 배포하여 사용하려고 했으나, organization 권한 문제로 배포할 수 없는 상태다. 2. 스토리북 빌드 파일을 gh-pages로 배포하자 GitHub는 GitHub Pages라는 정적 페이지 배포 환경을 제공한다. 정적 파일인 스토리북 빌드 파일을 배포해 보자. 3. GitHub Actions로 PR 날릴 때 Storybook 배포하기 매번 수동으로 빌드하고 배포하기보다는 자동으로 지속적인 배포를 하면 훨씬 편하다. GitHub Actions를 이용해 yml 스크립트를 작성해 보자. (vars.FE_DIRECTORY === ./frontend) 이제 PR을 날릴 때마다 스토리북 빌드와 배포가..

이 글은 동글이 반응형을 도입한 과정입니다. 1. 도입 계기 첫 배포를 마친 동글이 서비스로서 성공하려면 사용자가 있어야 한다. 그래서 다양한 루트로 홍보를 진행했는데, 페이스북 노션 그룹, 블로그, 카페, 카카오톡 오픈채팅방, 에브리타임, 인스타그램 등 많은 환경에서 홍보를 진행했다. 이전 글에서 확인할 수 있듯이 동글은 원래 PC 타깃으로 개발되었다. 하지만 카카오톡, 에브리타임, 인스타그램 등으로 유입된 사용자들은 모바일로 들어와서 첫 화면을 본다는 게 문제였고, 그 결과 첫인상이 좋지 않았다. 위 사진 말고도 반응형에 대한 피드백은 상당히 많았고, PC 퍼스트이긴 하지만 이를 계기로 모바일 지원을 고민하게 되었다. 2. 도입 과정 타겟 기기 선정: 휴대폰, 태블릿, PC 반응형을 코드로 작성하기 ..

이 글을 동글에서 낙관적 업데이트를 도입하기까지의 과정을 담은 글입니다. 1. 문제상황 업로드한 글의 제목을 바꿀 때, 정상 응답이 오기 전까지는 수정 전 제목이 보이는 문제가 있었다. 기능을 사용하는 데는 문제가 없지만 사용자는 불편하게 느낄 수 있고, 인터넷이 느린 환경에서는 더욱 문제가 된다. 그래서 요청이 성공했다고 가정하고 응답이 오기 전 요청 결과를 바로 반영하는 낙관적 업데이트 도입을 고민했다. 2. 낙관적 업데이트.. 꼭 필요할까? 그 전략이 좋아보인다고 해서 무턱대고 도입할 수는 없다. 사용자의 데이터 변경 요청을 빠르게 반영할 수 있다는 장점이 있지만, 서비스에 대한 사용자의 신뢰도 하락으로도 이어질 수 있다. 예를 들어 글 제목 변경 요청 후 재빨리 글 발행을 요청했는데 실제로는 글 ..

이 글은 동글을 개발하면서 MSW를 어떻게 하면 잘 활용할 수 있을지 고민하고 적용한 과정에 대한 글입니다. 또한 프론트엔드 개발에서 쓰이는 MSW에 대한 기본적인 이해가 있어야합니다. MSW를 이용해 개발을 해보신 경험이 있다면 더욱 좋습니다. 1. 데이터 모킹의 필요성 프로젝트를 만들면서 어떤 기능를 완성하기 까지는 기획 -> API 논의 -> 백엔드 개발 -> 프론트엔드 개발 -> 배포 의 단계를 거친다. 프론트는 데이터를 받아와서 유저가 보는 부분을 개발하기 때문에, 백엔드에 의존적일 수 밖에 없다. 하지만 공수기간을 맞추려면 마냥 백엔드 기능이 완성되기 까지 기다릴 수는 없다. 이때 API 문서를 보고 데이터를 모킹해서 개발할 수 있다. 2. MSW을 이용하며 마주한 문제 MSW를 이용하면 요청..

이전 렌더링 때보다 더 많은 훅을 렌더링했다는 뜻. 즉 훅의 호출횟수가 일정하지 않다는 뜻이다. 리액트 훅은 컴포넌트 내부 최상위 레벨에 선언해야한다. 즉 훅은 컴포넌트를 제외하고는 다른 블럭({ }) 내부에서 이용해서는 안된다 훅을 다음과 같이 선언하지는 않았는지 확인해보자. // 전부 잘못된 훅 호출 방식이다 // 1. 조건문 안에서 호출 if (someCondition) { useEffect(() => { ... }); } // 1.1 && 연산자 이용하여 조건부 호출 !value && useCustomHook(value) // 2. 반복문 안에서 호출 items.forEach(item => { useEffect(() => { ... }); }); // 3. 이벤트 핸들러나 다른 함수 내에서 호출 ..