Dev Diary

1. ./src 폴더와 하위에 index.html과 Index.js 파일 생성 index.html  크로스 브라우징에서 동일한 폰트가 Pretendard 웹 폰트를 적용했다. 2. package.json 생성npm init 프로젝트에 사용할 패키지 매니저를 이용해 init 명령어를 사용한다. npm install -D 사용할 패키지 매니저를 이용해 필요한 패키지들을 다운로드한다. 나는 아래와 같은 패키지들을 설치했다.-D를 붙이면 devDependencies에 패키지들이 설치되고, 이는 배포가 아닌개발 중에 사용할 패키지들임을 의미한다.webpack webpack-cli webpack-dev-server @babel/cli @babel/core @babel/preset-env babel-load..

드디어 회원가입의 마지막인 소셜 회원가입을 구현해보았다. 사실 소셜 회원가입은 구현해두면 로그인에도 같이 써먹을 수 있기 때문에 register 폴더 하위에 넣지 않고 따로 분리해주었다. 1. 카카오톡 간편 가입하기 버튼 클릭 시 카카오 로그인 화면 호출하기아래 이미지에서 카카오톡 간편 가입하기 버튼을 누르면 handleKakaoLogin() 함수를 통해 카카오 로그인 페이지를 호출할 수 있도록 해주었다. const handleKakaoLogin = () => { if (KAKAO_API_KEY && KAKAO_REDIRECT_URI) { const kakaoAuthUrl = `https://kauth.kakao.com/oauth/authorize?client_id=${KAKAO_API_..

이전에 만든 회원가입 정보 입력 폼에 이어 실제로 회원가입 버튼 클릭 시 기입한 이메일로 인증 메일을 전송하고, 메일 안에 있는 인증 링크를 클릭하면 가입이 완료되는 플로우를 완성해보았다. register 폴더 안에 container 라는 폴더를 생성 후 회원가입 플로우에 필요한 화면을 추가해주었다.registerOption: 카카오, 네이버, 구글, 이메일 가입 중 어떤 방식으로 가입할지 버튼을 통해 선택하는 화면register: 회원가입에 필요한 닉네임, 이메일, 전화번호 등을 기입하는 화면registerVerify: 이메일로 인증 메일을 전송하고, 인증 완료를 대기하는 화면registerResult: 회원가입 완료 시 redirect 되는 화면직관적인 파일명을 짓는 것은 항상 어렵다. 결과적으로 저..

드디어 길었던 디자인 시스템 작업이 끝났다. 자기소개서도 써보고 이력서랑 포트폴리오도 다듬느라 더 오래 걸렸다. 이제 슬슬 프로젝트를 완성하는데 집중해보려고 한다. 회원가입부터 만들어볼건데 진행중인 프로젝트에는 크게 2종류의 회원가입을 구현할 것이다.1. 자체 회원가입: 사용자의 이메일을 직접 기입해 회원가입한다.2. 소셜 회원가입: 네이버, 카카오, 구글 계정을 이용해 회원가입한다. 이번 게시글에서는 자체 회원가입을 구현해 볼 것이고, 핵심 기술로는 zod와 react-hook-form을 사용할 것이다.zod 왜 써?기존에는 입력 값의 검증을 하나하나 했었다. 만약 비밀번호를 입력받는데 영어, 숫자, 특수문자가 섞여있어야 한다는 조건이 있으면 useState로 password 상태를 하나 만들고 use..

배포된 Storybook 링크https://66d67775c0992d1453a0cffc-ibohkiaiwr.chromatic.com/ storybook - Storybook 66d67775c0992d1453a0cffc-ibohkiaiwr.chromatic.com 지금까지 한 작업물의 결과이전에 Storybook 설정에 관한 토이프로젝트 글 작성 후 Github에 Issue를 생성하여 할 일을 하나씩 꾸준히 해오고 있었다. 이제 필요한 UI 컴포넌트들을 대부분 구현 완료했으니 비록 다른 프론트엔드 팀원은 없지만 1명뿐인 백엔드 친구도 구현된 UI를 구경할 수 있게 하기위해 배포를 진행하기로 했다. Chromatic이란 것을 활용해 배포를 진행했는데, 이전에 Visual Test 연동을 하며 이미 Chrom..

지금까지의 프로젝트는 기능 구현에만 집중하여 진행했었다. 결과적으로 나중에 새로운 기능의 추가 혹은 기존 기능에 대한 수정 요청이 들어오면서 코드를 변경하게 되고 코드를 변경하면서 사소한 버그들이 자주 발생했던 경험을 겪었기 때문에 이번 프로젝트는 개발 시작 전 초기 설정 관련하여 시간이 훨씬 많이 걸리더라도 Storybook과 Testing Library 등을 도입하여 중요하거나 수정사항이 많이 발생할 것 같은 부분에 테스트 코드등을 추가하여 나중에 리팩토링을 진행하게 되었을때 사소한 버그가 출몰하여 그것도 수정하고 기존 코드도 수정해야하는데에 대한 스트레스를 줄이고 안정감을 느끼고 싶었다. Storybook과 Testing Library를 도입했을때의 전체적인 작업 흐름은 다음과 같다고한다.Story..

1. 공통 타입 분리하기// 분리, 인터페이스명 수정 @types/Building.tsinterface BuildingData { id?: number; name?: string; floorsUp?: number; floorsDown?: number; description?: string; latitude?: number; longitude?: number; uniqueNumber?: string;}interface EditBuildingResponse extends BuildingData { success: boolean;}interface FloorImage { buildingId?: number; description?: string; floorValue?: number; i..

지금까지 다수의 프로젝트를 진행했었지만, 실제 운영하는 서비스가 아닌 이상 지난 프로젝트 코드를 다시 열어본적은 거의 없었다. 하지만, 내가 그동안 얼마나 성장했는지 예전 코드를 보고 무언가 불편한점을 느낄 수 있는지 확인해보기 위해 1년전 프로젝트를 다시 열어보기로 했다. 타겟 프로젝트는 1년전에 대학교 재학 당시 코로나의 여파로 인해 처음 대면 활동을 시작하면서 학교 캠퍼스 지리를 잘 알지 못하는 재학생들과 신입생들을 대상으로 학교 내 건물과 강의실 위치를 제공해주기 위해 개발했던 서비스로 안타깝게도 지금은 운영하고 있지 않지만, 이를 내 나름대로 리팩토링을 진행해보기로 했다.어떤 것을 리팩토링할까?코드를 열어본 뒤 수정하면 좋을 것 같은 부분들을 생각해보았다.1. 공통 타입 분리하기api 요청시 요..