황채림/과제소개

[cofla159]

Readme

이번 선발과제의 리드미는 원티드에서 적으라는 것만 적었어서 이전에 만들었던 다른 프로젝트의 리드미를 설명해볼게요

배포 사이트랑 사용 스택을 간단하게 맨 위에 넣고 기획 의도를 밝혔습니다. 무엇을 의도하며 프로젝트를 만들었는지 프로젝트 기획 당시에 했던 이야기들을 정리했습니다.

그에 따른 문제와 페르소나입니다. 왜 이 서비스가 필요하다고 생각했는지를 담았습니다. 서비스를 만들 때 가장 중요한 것은 필요성이라고 여겼기 때문에 넣었습니다. 그에 따른 타겟팅으로 페르소나도 넣었구요.

기능 설명과 함께 시연 화면을 gif로 넣었습니다. 물론 배포되어있지만 회원가입과 로그인이 필요한 서비스를 직접 로그인해서 사용해보는 사람은 극히 드물것이라고 생각했어요. 특히나 면접관분들은 빠르게 보고 지나가기 때문에 간편하게 확인하는 방법이 좋다고 생각했습니다.

프로젝트의 세부 구조를 알 수 있는 내용들을 넣었습니다. 와이어프레임은 피그마 링크를 걸어두었고 API 문서는 개발하면서 노션에 정리한 페이지를 걸었습니다. 구성도도 그려서 넣었구요.

백엔드단은 데이터의 흐름이 중요한데 코드를 일일이 확인하지 않는 이상은 파악하기 어렵다고 생각해서 데이터 구조도를 넣었습니다.

마지막으로 팀원 각자의 역할과 담당한 기능들을 정리했습니다. 이 부분이 프로젝트에서 유일한 자기PR이기때문에 본인이 최대한 자세하게 작성하는게 좋다고 생각합니다. 면접관이 보기에도 좋고 본인 스스로도 나중에 잊어버리면 다시 확인하기 좋더라구요.

로그인

저는 회원가입하고 로그인 페이지를 분리했습니다. 회원가입 창을 페이지 이동 없이 모달로 띄우는게 베스트라고 생각했는데 시간이 부족해서 그냥 페이지 분리로 그쳤습니다.

로그인 페이지에 들어오자마자 토큰을 확인해서 로그인 정보가 있으면 투두 페이지로 리다이렉트 시켰습니다.

로그인 컴포넌트에서는 `onChange`로 입력값이 바뀔 때마다 input 태그의 값이 바뀌도록 했고, 동시에 유효성 검사를 진행해서 `isValidate` 객체에 이메일과 패스워드로 나눠서 담도록 했습니다. 확인 버튼은 `isValidate`가 모두 `true`일 때만 활성화되도록 하고 버튼을 누르면 `form` 태그의 `onSubmit`이 동작해 api 통신이 이루어지도록 했습니다.

`onSubmit`의 함수인데요, 로그인 외에도 api 통신하는 함수는 모두 똑같은 구성을 가졌습니다. try-catch로 통신을 시도하고 결과값을 받아서 이후의 과정을 진행하거나, 에러가 났을 때에는 이용자에게 알려 다시 시도하도록 했습니다. 저는 이 에러핸들링 부분이 사용자 경험에 상당히 중요한 부분을 차지한다고 생각합니다. 뭔가 에러가 나서 원하는 기능이 수행이 안됐는데 이유도 모르겠고 먹통이 된다면 페이지 이탈의 확률이 높아지니까요.

CRUD

todo 리스트를 불러오는 getTodos 함수를 만들어서 처음 페이지 접속 시 토큰이 없다면 로그인 페이지로 리다이렉트, 있다면 리스트를 불러오도록 했습니다.

항목 추가는 로그인 로직과 거의 동일하게 구성했습니다. 입력값이 바뀔 때 `onChange`로 `createContent` 변수에 담고 추가 버튼을 누르면 `form`의 `onSubmit`으로 api 통신이 일어나는 방식으로요.

수정과 삭제는 todo 각 항목 내부에서 진행되도록 했습니다. update/delete 핸들러를 `TodoItem` 내부에서 구현하지 않고 전달한 것은 api 통신에 todo 항목 하나가 아니라 todos 리스트 전체가 필요하기 때문이었는데 지금 생각해보니 delete 핸들러는 그럴 필요가 없었네요.

TodoItems 컴포넌트에서는 체크박스를 만들어 완료 처리를 할 수 있도록 했습니다. todo 객체에 `isCompleted` 요소로 완료 여부를 넣고 그게 바뀐다면 업데이트 하도록 했습니다.

수정 시의 화면 구성은 `editing` 변수에 수정 상태를 boolean 값으로 넣어서 삼항연산자를 활용해 `true`라면 수정에 필요한 `input`과 완료/취소 버튼이 나오도록 했습니다. 역시 `input`의 `onChange`는 입력값이 변할때마다 변수에 담는 역할입니다. 완료를 누르면 업데이트핸들러를 호출한 뒤 `editing` 값을 `false`로, 취소는 업데이트 없이 `false`로 바꿔서 구현했습니다.

아까 삼항연산자에서 `editing` 값이 `false`라면 기존의 todo 내용과 수정/삭제 버튼이 나옵니다. 수정 버튼은 `editing` 변수를 바꿔 `input` 요소를 나오게 하는 역할이고, 삭제는 아이디를 전달해 해당 항목을 삭제합니다.

위에서 설명한 내용은 모두 컴포넌트들이었고, 이 컴포넌트들을 모아주는 페이지 컴포넌트를 따로 만들었습니다. 여러 컴포넌트 조각을 모아 큰 페이지를 구성하는게 리액트의 본래 목적이기 때문에 그에 가장 적합한 구성이라고 생각합니다. 원래는 페이지 컴포넌트는 어떤 비즈니스 로직도 들어가지 않고 오직 **컴포넌트를 모아주는 역할**만 해야 한다고 생각하는데 이번에는 시간이 촉박해서 로그아웃 로직을 넣어버렸네요.

스타일

스타일링은 보기 불편하지 않은 정도만 했습니다. tailwindCSS를 사용했는데, 가장 큰 이유는 많이 사용해서 손에 익어서였습니다. 조금만 익숙해지면 키워드만으로 금방 스타일링하기 쉽기도 하고 이미 만들어진 예시 컴포넌트들이 많아 고급 스타일링들을 가져다 사용하기에도 좋습니다.
저는 styled-component는 코드를 볼 때 해당 요소가 어떤 태그인지 한 눈에 들어오지 않아 선호하지 않습니다.

컨벤션

lint는 가장 유명한 에어비엔비 설정을 사용했습니다. 제약 조건이 많아서 처음 사용하면 에러가 많이 뜨긴 하는데, 사용하다 보면 그만큼 심각한 에러가 날 만한 상황을 막아주어 좋습니다.
prettier도 사용하고 있는데 들여쓰기 2칸, 세미콜론 자동 정도의 간단한 설정으로 사용하고 있습니다.