TangWay항공

티웨이 항공 홈페이지 클론 프로젝트

팀 구성

Front: 최용석, 임대호, 김찬영, 강경오
Back: 최선우, 문승희

프로젝트 기간: 2020.12.28 ~ 2021.01.08

Front-End 기술 스택

1. HTML
2. ES6
3. JavaScript
4. React(CRA)
5. Sass
6. Redux
7. styled-component

협업 도구

1. GitHub : Git rebase 사용하여 flow 진행
2. Slack : 비대면 소통
3. Trello : 일정관리 및 작업 현황 공유
4. Notion : 팀 내 개발 자료, 규칙, 안건등 기록

Front-End 구현 페이지

1. 로그인(+소셜로그인), 회원가입 (강경오)
2. 메인 (임대호)
3. 항공권 예매 (최용석)
4. 탑승자 정보 (김찬영)

repo

= https://github.com/wecode-bootcamp-korea/15-2nd-tangWay-frontend

내가 작업한 내용

1. 회원가입
   • 아이디는 이메일 형식으로 제한
     - 정규식을 활용해 아이디의 형식을 체크하고 한글은 입력이 불가능하게 제한.
     - fetch를 이용한 API 통신으로 중복 체크 기능 구현
   • 비밀번호 또한 정규식을 이용해 필수 포함 문자가 없을 때 경고를 띄우고 가입이 안되게 제한.
   • Fetch post로 입력 받은 사용자의 데이터를 서버로 보내주고 등록.
   • Router를 이용해 가입 완료 후 로그인 페이지로 이동.

2. 로그인 (+소셜로그인)
   • 카카오 로그인 시 카카오 API에서 사용자 정보를 가져와 소셜 로그인 기능 구현
     - 서버에 없는 사용자일 경우 카카오에서 받은 정보는 redux로 state에 저장해 두고 부족한 정보를 입력 받기 위해 회원가입 페이지로 이동
     - 서버이 있는 사용자일 경우 서버에서 토큰을 받고 로그인 후 메인 페이지로 이동
     - 카카오에서 받아온 정보는 미리 입력 시켜놓고(redux) 부족한 정보만 입력 가능하게 구현
   • fetch를 이용해 사용자 정보를 서버로 보내고 인가 받은 사용자의 경우 토큰을 받아옴.
     - 이후 토큰을 이용해 사용자를 확인하기 위해 로컬스토리지에 저장

3. 추가 구현 내용
   • 약관 페이지
     - 체크박스 전체 선택 및 전체 해제 (state로 관리)
     - 전체 선택 후 하나 체크 해제 시 전체 해제
   • 회원 정보 모달
   • 페이지 푸터 ui

느낀 점

1차 때는 class component를 사용해 프로젝트를 진행했던 반면 이번 프로젝트에서는 함수형 컴포넌트, hooks, redux, styled-component 등 많은 것을 배우고 프로젝트에 적용하여 진행했기 때문에 여러모로 바쁜 2주였지만 그만큼 성취감이 느껴지는 기간이었다

특히 이번 프로젝트를 시작하면서 컴포넌트의 구조에 대해 많은 생각을 해보게 된 것 같다. 1차 프로젝트 때는 처음 실제 페이지를 만들어보는 상황이었기 때문에 일단 구현 자체가 목적이었다면 이번 프로젝트 때는 더 깔끔한 컴포넌트 구조와 가독성 그리고 컴포넌트의 재사용성에 대해 나름대로 고민을 하고 진행을 했다. 나름대로 고민의 결과로 UI와 로직을 구분해서 컴포넌트를 만들자는 결론을 내렸고 최상위 컴포넌트에서 로직을 가지고 하위 컴포넌트들로 보내주는 방식으로 구성을 하려고 했다. 물론 중간 중간 막히는 부분도 많았고 이런 구조에 대한 확신도 없었기 때문에 결과물을 봤을 때 처음 생각한 대로만 나오지는 않았다. 이후 짬짬히 공부해 본 결과 HOC나 커스텀 훅을 이용하면 더 깔끔하게 UI와 로직을 분리 시킬 수 있고 컴포넌트의 재사용성을 늘리고 구조를 단순화할 수 있다는것도 알았지만 촉박한 시간 탓에 수정을 하지 못한 것이 좀 아쉬운 부분이다.

두번째로 많이 고민했던 것은 state관리이다. 처음에는 위의 로직처럼 최상위 컴포넌트에서 전부 관리하고 하위 컴포넌트들로 내려주는 것이 컴포넌트 구조 상 깔끔하고 이후에 오류가 날 경우 수정에 용이할 것 같아 이렇게 진행했다. 하지만 진행하던 중 최상위에서 모든 스테이트를 관리하게 될 경우의 문제점을 발견 했는데 최상위에서 모든 스테이트를 가지고 있기 때문에 어떤 스테이트라도 하나만 바뀌면 모든 컴포넌트가 리렌더링된다는 점이다. 또한 컴포넌트 구조상 최상위의 하위 컴포넌트 또한 하위 컴포넌트를 가지고 있는 경우도 있었는데 이 경우 중간 컴포넌트를 거쳐서 하위로 가기 때문에 필요없는 스테이트를 가지고 있게 되는 경우도 있었다. 어쨋든 가장 큰 문제는 컴포넌트 전체의 렌더링이 너무 자주 일어난다는 것이었고 알아챈 시기부터는 최대한 이런 상황을 피하려고 했고 초기 스테이트들도 수정한다고 했는데 잘 됐는지는 아직 확신이 들지 않는다. 스테이트는 필요한 컴포넌트들에 모두 줄 수 있는 위치까지만 올려주고 사용하는 것이 최적화 면에서 좋다는 것을 배우게 된 계기였다.

1차 때도 그랬지만 여러가지로 시도해보고 싶은 것, 나중에 알아챈 내 코드의 문제점 수정 등 할 게 많았지만 2주라는 시간이 참 짧은 것 같다. 촉박한 시간 내로 팀 나름대로의 결과물은 내놓았고 만족할 만한 결과라고 생각하지만 팀원 모두 하나 둘씩 아쉬운 점, 시도해보고 싶은 점, 수정하고 싶은 점 등이 있었던 것 같다. 앞으로 실력을 더 키워서 정해진 기한 내로 최소한 리팩토링은 가능할 정도의 개발자를 목표로 잡고 공부를 더 해야겠다.