오랜만의 윙글이다. API 연결 이후 그동안 자잘한 수정점은 있었지만 기록을 따로 하진 않았다. QA를 진행하면서 디자인 수정점이 있었고, 디자인 수정 뿐만 아니라 공통 UI 제작이 있었다. 적용을 하기 전 코드 분리를 먼저 해 운영 보수를 보다 쉽게 하겠다. signUpInput.tsx 분석 500줄 가까이나 되는 엄청 큰 파일이고, 이메일부터 패스워드까지 모든 로직과 UI가 한 파일에 있었다. 사실 만들면서도 리팩토링해야겠다 생각은 했지만 API 연결이 급선무였기 때문에 먼저 연결을 하고, 리팩토링을 진행하려고 했다. 이메일 인증메일 보내기 sendEmail 함수를 호출하여 이메일 인증메일을 보냄. useMutation 훅을 사용하여 비동기 요청을 처리하고, onMutate, onSuccess, onError 콜백을 사용하여 요청의 상태에 따라 UI를 업데이트. 이메일 인증번호 확인 verifyEmail 함수를 호출하여 이메일 인증번

취업을 하며 그 사장님? CEO?가 이 구조에 대해서 여기 사이트를 보며 알아놓으면 좋다고 하길래 알아놓기 위해 이렇게 기록으로 남긴다. 사이트 보고 나서 너무 무서워서 쓸 수 밖에 없었다.. 한번 봤는데 어질어질한 사이트.. 아직 호칭도 어색한 쌩신입니다.. OAuth 2.0이란 >인증 및 인가 프로토콜로서, 인터넷에서 클라이언트 애플리케이션이 사용자 리소스에 대한 접근 권한을 안전하게 위임할 수 있도록 할 수 있는 프레임워크, 클라이언트-서버 모델을 기반으로 한다. 다양하게 정의되고 있다. Wikipedia 다른 웹사이트 상에 있는 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 수단으로 사용되는, 접근 위임을 위한 개방형 표준 [RFC](https://www

전 글에는 드롭다운의 로직을 짜봤다. 이제 만든 Props를 가지고 연결해보자. 모델 다시 보기: interface 전편에 만들었던 드롭다운 Props interface를 다시 보자. 위와 같다. 이제 클릭할 때 드롭다운의 내용이 변하고, disabled, 제목 등의 디자인을 해보자. 기능 구현 상태 getter / setter 함수 연결하기 전에 text.tsx에 썼던 const [selected, setSelected] = useState(""); 문장을 썼고 그를 Props로 내려줬다. 값을 바꾸기위해 setter인 handleSelectedChange로 setSelected를 받아주도록 연결하고, getter인 selected를 값으로 연결해 받아줄 것이다. handleSelect에 handleSelectedChange 작성 handleSelectedChange는 setter함수

이제 드롭다운을 만들어 보겠다. 디자인/기능 기획 드롭다운 내장 태그인 select는 당연히 못쓴다. 디자인 커스텀이 제한적이기 때문에! 그래서 위 사진 같이 드롭다운을 눌렀을 때 div가 나와야한다. 또 선택 전, 선택 중, 선택 후 border, Text color가 달라져야하고, disable가 있다. 그리고 Hover되거나, Selected가 된 요소들은 다른 배경색을 가져야한다. 구현해야할 게 많다 너무 기능구현 이제 만들어보자! Props 제작 저렇게 텍스트로 받아야하니 string으로 된 배열을 하나 받고, 선택된 항목을 관리하는 상태, 선택을 관리해주는 핸들러, Input에서 했던 것처럼 disabled, 제목 받는 label, `desc

이제 길고 긴 API 연결은 끝이 났다. ㄹㅇ 기록하는 것도 일이다 일이야.. 이제 QA와 알파테스트 준비하고, 리팩토링하고 그래야하는데 중간에 디자인이 바뀌었고, 그에 맞게 공통 UI를 만들어야한다고 프론트에서 협의해서 만들기로 했다! 고기릿 해보자. 디자인 및 기획 위 사진처럼 디자이너분이 공통 UI를 만들어 놨다. Color부터 Text, Button, Input, 드롭다운 등등을 설정하고 재사용하라고 저렇게 작성해주셨다. 압도적 감사! 그래서 Styled-Component로 Props를 사용해 만들자고 협의 봤다. 무슨 말이냐면 아래 theme을 만든 예시를 보면 알 것이다. 이런 식으로 말이다! 이렇게 만드는데 Input은 디자인 요소만이 아닌 TSX 부분도 필요하기 때문에 쓰는 P

전편에 이어서 API 연결과 리액트쿼리를 구현해 요청을 기어코 보내보겠다! API 명세서 제일 처음에 보여줬던 회원가입 API 명세서를 봐보자. > Request Body 🚨 multipart/form-data로 주셔야 합니다! 항목 idCardImage string, 학생증 이미지 email string, 이메일 password string, 비밀번호 name string, 이름 isNicknameChecked boolean, 닉네임 중복 검사를 통과했는지 nickname string, 닉네임 gender boolean, 성별, 여자가 true nation string, 국적 termsOfUse boolean, 이용약관 동의 여부 termsOfPersonalInformation boolean, 개인정보 수집 및 이용동의 여부 termsOfPromotion boolean, 이벤트 프로모션 알림 동의 여부 예시 저 데이터에

이제 회원가입 막바지이다. 그동안 다른 컴포넌트에서 다 회원가입 데이터를 주고 받는 컴포넌트를 작성했다면 이번에는 Atom을 검사하고, 필수적인 데이터들이 다 들어왔다면 API 요청을 보낼 수 있게 할 것이다! 디자인 / 기능 기획 이렇게 피그마를 보면 순서대로 배치가 되고, 필수 데이터들이 다 들어오면 바로 버튼이 활성화가 된다. 즉, 필요한 건 아래와 같다. 나머지 TSX 부분 디자인 및 그동안 만든 컴포넌트 5개 넣기 버튼 disabled하게 만드는 상태 추가 리코일 아톰을 불러오고, 아톰이 변경되는 순간 감지할 수 있는 useEffect가 필요 API 호출 코드 작성하기 useMutation을 사용해 API 호출 실행하기 할 게 되게 많다.. 1번부터 차근

이제 signup 막바지다. 성별을 클릭하는 라디오 버튼, 이용약관 필수 및 선택 버튼을 만들어보자! 라디오 버튼 기능 / 디자인 기획 이런 식으로 만들면 된다. 한 곳을 클릭하면 다른 한곳의 값은 안되게 하나의 상태로 관리해야한다. 2개로 관리하고, 서버에도 boolean 데이터로 리코일아톰에 담아 보내줘야한다. true면 여자고, false면 남자다. 남자는 가짜인가?! 디자인 코드는 아래와 같다. 이미지를 불러와 src에서 불린 데이터로 조건을 나눴다. 불린 데이터로 라디오 버튼이 주황색, 회색으로 바뀐다. 이제 리코일 아톰에 담길 수 있게 기능을 넣어주자. 아톰 아들 : 배고파요 useEffect 엄마 남자, 여자를 클릭할 때마다 아톰에 담기게 하고

이제 국가를 설정하는 드롭다운 메뉴를 만들 것이다. 되게 간단하다! 기능 / 디자인 기획 먼저 피그마는 아래와 같이 있었다. 나라 리스트를 드롭다운에 넣을 수 있게 배열 하나 만들기 초깃값을 Republic of Korea으로 선택하면 선택된 값을 리코일 아톰에 넣기 이런 식으로 가면 될 것이다. 사실 노가다가 좀 많긴 하다. 드롭다운 UI 만들기 먼저 기본적인 형태를 만들어보자. 여기서 내장 드롭다운 태그인 label + select 태그를 사용하지 않을 것이다. 왜냐하면 피그마에서 디자인한 것처럼 만들어야하는데 CSS를 적용하는데 한계가 있기 때문이다. onClick 이벤트로 드롭다운 리스트가 보이도록 하는 div를 만드는 핸들러를 선택된 요소가 보이는 `di

전편에 이어서 이메일 확인 인증번호를 받는 기능부터 만들어보겠다. emailVerify 우선 인증번호를 받고 check 하는 기능을 연결한 버튼에 연결할 API 코드를 먼저 구현해보자. API 통신 먼저 API 스펙을 보자. certificationKey: string, 인증번호 key, email을 넣으면 됨 certificationCode: string, 인증번호 (사용자가 입력한 인증번호) 이런 식으로 받는다. 이제 post 해보자. 요청과 응답을 받는 타입과 verifyEmailCertification를 구현했다. 리턴에 불린데이터인 available를 리턴하고, 아니면 false를 리턴하게 만들었다. 즉, 결과물에 따라 true면 인증 성공으로 상태를 변경해주고, false면 오류뜨게 만들면 된다. 리액트쿼리 기능 구현 이렇게 만들었다. 전편 email을 넣어서 상태를 변경시킨 것처럼 isError~

이제 사진을 담고 리코일 아톰에 보냈으니 input을 관리해보자. 디자인/기능 기획 구현할 구역은 다음과 같다. 위에 맞게 기획해보자면 이메일 전송 및 인증번호 확인 input/API 연결 및 유효성 검사 비밀번호 및 확인 input 및 유효성 검사 실명-이름 input 및 유효성 검사 닉네임 input/API 연결 및 유효성 검사 참고: 디자인만 된 코드 진짜 겁나 길다; 300줄 이상이라 그렇다. 보기 싫다면 넘어가는걸 추천한다. 벨로그는 드롭다운이 왜 없나몰라 buttonMessage, emailMent 등으로 에러 시 나올 메세지나 완료시 메시지를 넣으려고 했고, inputData로 데이터를 따로 관리했다. 불린데이터인 isError~를 넣어

회원가입 인증 사진을 담겠다! 일단 전 글에 말한 대로 디자인과 구성은 미리 끝내놓은 상태다. 디자인 이렇게 하고 포인트는 완료 기준 삼아 complete라는 상태를 만든 것과 전편에서 봤듯이 사진, input, 드롭다운 등으로 나눠 컴포넌트로 나눴다. 나중에 input은 바뀔 수도 있다! 이제 StudentCard를 만드러 보자. StudentCard 제작 우선 기능 / 디자인을 봐야겠지? 디자인은 위와 같고, ?를 누르면 위에 팝오버가 뜨게 된다. 또 버튼을 눌러 업로드, 즉 `<input type="file

이번엔 회원가입이다. 우선 먼저 상황을 보자면 디자인만 되어있어서 분석하기 이렇게 돼있었다. 즉, 디자인만 돼있어서 여기에 제출버튼을 눌러야하고, 컴포넌트식으로 다 전부 쪼개져있으니 StudentCard 부터 S.CompleteButton를 form 태그로 묶어 제출 버튼을 누를 때 그 데이터들이 날아가게 변경 로그인과는 다르게 회원가입은 기능이 많아 컴포넌트로 분리된 것들이 많음. 즉 리코일을 써야한다는 얘기.. 으아아 회원가입은 API도 4개가 있고 FormData로 넣어야하는 등 좀 많아서 기능별로 작성하겠다. 구현해야할 기능/디자인 살펴보기 기능 이렇게 노션에 정리돼 있다. auth/signup 도메인에 결과적으로 요청을 하는 것이다. 보내야할 데이터 내용

이제 토큰을 받아올 준비가 됐으니 로그인 페이지를 만들어 POST를 하고 아이디, 비밀번호를 입력해 버튼을 누르면 토큰을 받아 로컬스토리지에 넣는 방식까지 만들어 보겠다. 개발 전 준비 먼저 내 상황을 말해보겠다. 피그마로 디자인 팀, UI/UX 팀이 디자인을 만들어 놓은 상태. 전 프론트 팀이 만들어 놓은 기본적인 디자인 코드 구현. 이런 상태였다. 2번에서 미리 만들어 놓은 상태이긴 하지만 라우팅, 유효성 검사, 버튼 기능 X, POST API 등 부족한 것이 많았다. 완전 초기 상태. 초기 코드를 보면 알겠지만 간단한 CSS만 구현이 되어 있고, 기능면은 아예 없다. 이제 순서대로 훑어 내려가보자 리팩토링 먼저 지금 팀에서 쓰는 문법 및 작성 방법을 통일해야한다. 세부 내용

전편에서 보았듯이 세팅 끝났고, 이제 서로 맡은 바에 최선을 하기 시작한다! 나는 이제 인증 관련 개발을 맡았다. 로그인, 회원가입, 토큰 관리 등을 맡으려고 하고있다. 토큰 관리 우선 토큰을 어떻게 처리해야할지 생각해보자. 백엔드에서 토큰 방식은 JWT로 보내주신다. 액세스토큰은 30분, 리프레쉬토큰은 7일로 유효기간을 잡고 있다. 리프레쉬 토큰은 로컬스토리지에 넣고, 액세스토큰은 페이로드에 사용자 정보인 이메일이 들어가 있어 이거는 노출이 안되게 로컬 변수에 넣어야하나 싶었지만 일단은 로컬스토리지로 하기로 협의했다. 로컬스토리지 간단하다. 로컬스토리지에 넣고, 읽어올 함수만 구현한다. 이렇게 하고, save는 로그인할 때와 리프레쉬로 액세스 토큰 가져올 때 쓸거고, get은 이제 권한이 필요할 때, header나 로그인 됐는지 안됐는지의 조건에 쓸 것이다. axios interceptor 이제 토큰 저장 관리는 끝냈다. 우리 웹의 특징은 로그인을 해야

이제 초기 개발 세팅을 해보자. 전에도 얘기했지만 기획부터 디자인, UI/UX는 피그마에 돼있어서 그 기획된 기능을 프론트 팀원 5명 서로 나눠서 구현하기로 했다. 일단 5명 브랜치 파기 전에 develop 브랜치에 기본 개발 세팅부터 하자. 폴더 구조, 파일명 설정 전에 얘기했듯이 폴더 및 파일 구조가 정해지지 않아서 중구난방이었다. 그래서 위 사진과 같이 폴더를 짰다. modules빼고 다른 걸 모두 만들었다. 네트워크 호출 코드 관련 api, ui 구현하는 components, pages, 색상 관련 theme파일이 있는 styles 등이 있다. 잘게 분리하면 좋은게 추후 리팩토링이나 유지보수시에 도움되니까 이렇게 나눴다. 폴더 및 파일명 네이밍도 통일돼있지 않아서 `lowerCamelCase

나는 취업 문턱에 가로막혀 슬프게 질질 짜고 있었다. 하지만 문득 생각이 들었다. 무엇이 나를 가로막는지 알고 싶었다. 직접 배민에서 일하시는 분에게 질문을 드려 첨삭을 받아본 결과, '신입인데 포트폴리오가 일단 매우 적다.'라는 말을 들었다. 바로 목표 설정에 들어갔다. 부트캠프에서 팀프로젝트 1개만 있었지만, 내 개인 프로젝트와 팀프로젝트 하나씩 더 구현해서 올해 상반기 안으로 3개를 만들어 보겠다고. 동시에 부족한 기술스택을 사용하며 구현력에 힘을 더 싣겠다고 다짐했다. 그 결과 개인은 VarGen으로 구현했다. 팀 프로젝트도 만들고 싶었기에 일주일 동안 사이트 프로젝트 사이트를 돌아다녀본 결과 윙글이라는 프로젝트를 보게 됐고, 지원해서 합류하게 됐다. Wingle Wingle, 통칭 윙글은 어느 한 대학교에서 프로젝트 지원을 받아 만든 것이라고 한다. 대학교 커뮤니티를 만드는 것이었다. 에타보다 좀 더 범용적인 느낌의 커뮤니티면서 보안을 좀 높인 커뮤니티다. 좀