[team-12] Eamon & Autumn 3주차 PR

[deprecated-hongbiii]

1. 진행상황

로그인

• github OAuth 를 이용해서 code 를 백엔드 서버에 보내주고 JWT 인증 토큰을 받아오기
• JWT 토큰을 디코딩 하여 로그인한 사용자의 정보로 profile img 를 바꿔서 headr 에 렌더링 해주기
• 모든 api 요청의 header 에 token 을 넣어서 요청.
• 로그 아웃 구현
• 모든 페이지에서 로그 아웃 시 로그인 페이지로 리다이렉트

이슈 목록 페이지

• Tab UI를 이용하여 열린이슈/닫힌이슈 조회
• 조건별 검색

이슈 생성 페이지

• 이슈 생성 - 담당자, 라벨, 마일스톤 지정 가능
• 파일 첨부
• 마크다운 입력

이슈 상세 페이지

• 코멘트 생성
• 라벨 수정
• 마일스톤 수정
• 코멘트 수정
• 코멘트 삭제
• 이모지 리액션
• 파일 첨부
• 이슈 닫기 / 다시 열기
• 이슈 삭제

라벨 목록 페이지

• 라벨 생성
• 라벨 수정
• 라벨 삭제

마일스톤 목록 페이지

• 마일스톤 생성
• 마일스톤 수정
• 마일스톤 삭제

2. 고민한 내용

여러가지 방식의 비동기 API 요청 방법

1. useAxios 와 같은 custom Hook 사용
2. Recoil selector 를 이용한 비동기 요청
3. axios 의 Interceptor 를 이용한 비동기요청

세 가지 방법을 모두 사용해보았습니다.

에러처리

(현재 방식)
store.ts에서 get 요청이 발생하는 selector에 try & catch 처리를 해주었다.

(개선 방식)
비동기가 일어나는 로직에서는 에러를 throw 만해주고 그 데이터를 가지고 렌더하는 컴포넌트에서는 error 를 catch 해서 에러 발생시에 적절한 다른 컴포넌트를 렌더링한다.

Recoil 의 적절한 사용방법

1. Recoil selector 에서 비동기 요청이 pending 상태일때 Suspense 에 fallback 에 저장되어있는 컴포넌트가 렌더링된다.
   👉 이 현상때문에 비동기 요청을 다시 보낼 때 화면이 깜빡임. (예시 상황 - 라벨 목록 페이지에서 라벨 생성/편집/삭제 후 get 요청을 받아서 다시 렌더링 할 때)
   (해결책) useRecoilValueLoadable 훅을 사용하자.

2. selector 함수는 순수함수이기 때문에 구독하는 atom 의 값이 같으면 이전 값을 return 한다.

• 요청을 다시 trigger 하기 위해서 true/ false 값을 가진 atom 을 만들고 요청을 다시 보낼때마다 그 값을 바꿔 줬는데 이전 값이 다시 나왔다.
• (해결 방법) trigger atom을 boolean이 아닌, 요청이 필요할 때마다 숫자를 +1 해주는 방법으로 해결

3. 데모 영상

4. 느낀점

Autumn

• [에러 처리] 이번 프로젝트에서는 서버와 통신이 많다 보니 특히나 에러 처리의 중요성을 많이 느꼈습니다. 에러처리를 해놓지 않았더니, 개발 단계에서 API나 서버에 문제가 있을 때 화면이 아예 안 나오는 문제를 겪었습니다. 프론트 단의 에러 처리 뿐 아니라 서버 쪽에서도 에러 처리를 잘 해주어야 http 통신 과정에서 디버깅 시간을 줄일 수 있겠다는 생각을 했습니다.
• [협업] 로직, 설계 과정을 함께 진행하면서 서로 제안과 질문을 많이 했습니다. 이전에는 팀원을 따라가기 바빴는데 저의 보폭에 맞춰준 이어몬 덕분에 함께 프로젝트를 재미있게 할 수 있었습니다. 백엔드와의 협업에 있어서는 많이 개선을 해야겠다는 생각을 했습니다. API 요청사항이나 변경사항이 있을 때 슬랙 채팅 말고 체계적인 관리 툴이 있으면 작업이 편리할 것 같았어요.
• [상태 관리] 이번에 recoil을 처음 사용해봤는데 모든 컴포넌트에서 recoil 상태에 접근할 수 있는 점이 편리했습니다. 상태 뿐 아니라 에러 처리, 비동기 처리 등등 다양한 부분을 지원해줘서 좋은 라이브러리라고 느꼈습니다. 프로젝트를 하며 경험해 본 props drilling, Context API, recoil의 장단점을 비교하고 블로그에 정리해보는 시간을 가져야겠습니다.

Eamon
'서로 질문하며 성장하는 협업'이 무엇인지 알았던 3주였습니다. 마지막 미션이여서 그런지 치밀한 설계 계획 이나 팀원의 협업룰을 정하는 것보다도 서로 '그냥 알고지나가는 것들'을 되묻고 같이 공부하는 시간이라서 값진 시간이였습니다.

http 통신과 백엔드와의 디버깅에서 크롬의 네트워크 개발자 탭과 더 친해진 느낌이 있었지만 백엔드와 프론트엔드 모두 에러처리를 치밀하지 않게 해놓아서 개발자 탭으로 하는 디버깅이 무용지물이고 답답함을 느꼈습니다. 그렇기 때문에 효율적인 디버깅을 위해서는 프론트와 백엔드 모두 에러처리를 해야한 다는 점을 느꼈습니다.