팀05 프론트엔드 중간 피드백 면담

0. 오늘의 멘토링 정리

1. 진행상황 공유

a.공통컴포넌트

• 깃헙 components 폴더에 구현 되어 있는 사항들

b.인증/인가

• kakao Oauth 로그인

• 페이지 이동시 로그인 유지

• PostPage에 대한 인가 처리

c. 라이딩개설폼

d. 라이딩 디테일 페이지

• 페이지 구성 중
• mock data를 public 폴더 아래 생성 후 이를 react-query를 통하여 fetch 후 페이지 구성 중
• MUI의 Grid 컴포넌트를 이용하여 layout을 잡고 있음
• 각각 필요한 section을 컴포넌트화 해서 detailpage 파일에서는 이 컴포넌트를 조합한 형태로 만들 예정(Grid 잡는 것은 detailpage 에서 잡아줌)

e. 남은작업들

• 프로필 페이지, 메인페이지, 디테일페이지, 알림

f. 중간 KPT 회고

2. 질문 사항 공유

Q1. env 배포서버에서 못 읽는 이슈, 문제 원인을 어디로 좁힐 수 있을까요? [트리]

Q2. ducksPattern 사용시 constants나 간단한 util함수의 위치는 어디가 좋을까요? [트리]

• [문제상황] 회원정보를 추가 등록하는 RegisterForm 파일에서 주요로직이 아닌
• Select의 option을 생성, 파싱하는 함수들
• Select의 optionBox의 height을 지정하기 위한 상수들

• [현재해결]
• RegisterPage/registerService.ts
• 세부로직을 담당하는 util함수와 상수들 저장

• [의문]
• 현재 ducksPattern 사용방식의 의문
• 각 페이지별 마다 component, hooks, -service 로 두는 것이 잘 사용하고 있는 방향인가?

Q3. 폴더 구조

• [의문점]
하나의 컴포넌트를 다른 컴포넌트들을 합쳐서 구현할 때 폴더의 상하 관계는 어떻게 하는 것이 일반적인지 궁금합니다.

• [현재 상황]
PostForm 컴포넌트를 구성하는 여러가지 Input 컴포넌트를 동일한 디렉토리에 포함

Q4. React-Hook-Form 관련 질문

Q4-1. useFormContext 사용

앞서 보여드린 대로 PostForm 컴포넌트는 여러 Input 컴포넌트를 하나의 Form에서 처리합니다. 이를 위해서 각 Input 컴포넌트는 React-Hook-Form의 useFormContext API를 사용하고 있습니다.

그로 인해서 모든 Input 컴포넌트는 동일한 코드가 반복되고 있습니다.

• useFormContext의 register를 생성하는 코드

• <Input> 에 props로 전달하는 코드

이러한 구조가 개선이 필요하다 느끼지만 개선하기가 어렵습니다.

그리고 꼭 useFormContext를 사용해야 하는지 대체할 수 있는 다른 방법이 있는지도 궁금합니다.

Q4-2. value와 submit하는 값이 다른 Input 컴포넌트

[의문점] 사용자에게 보여주고 싶은 값과 서버로 전송하려는 값이 다를 때 어떻게 관리하는 것이 좋을지.

[예시]

위 사진은 주소를 입력하는 컴포넌트입니다. 사용자에게는 주소를 출력하고 서버에는 좌표(위도, 경도) 데이터를 전송합니다.

const InvisibleDiv = styled.div`
  display: none;
`;

<Input
  readOnly
  fullWidth
  placeholder="주소"
  value={addressString}
/>
...
<InvisibleDiv>
	<Input
	  {...register("information.departurePlace", {
	    required: "필수 입력항목입니다.",
	  })}
	/>
</InvisibleDiv>

지금은 readOnly로 사용하여 값만 변경하는 Input과 react-hook-form 을 사용해 좌표값을 Form에 전달하는 보이지 않는 Input이 존재합니다.

Q4-3. Input Error 표기 시 이슈

💡

[의문점] react-hook-form 사용 시 모든 input의 error를 object 형태로 전달받습니다. 어떤 error가 가장 상단의 입력에서 발생하는지 알 수 있는 방법이 있을지 궁금합니다.

UI/UX 적으로 모든 input의 에러가 표시되는 것 대신 가장 위의 입력만 표시되는 것이 적절하다 생각합니다.

• 예시

 

Q5. zenhub 사용시 epic 구분/범위

• [현재]
• 같은 Domain 업무에 대해 front/server 각각 Epic을 생성
• “한눈에 보기 어렵다”
• 하나의 Epic을 생성하게 된다면, Epic도 하나의 issue이기에 front/server 중 한 곳에 생성해야함
• 올바른 프로세스인가?

• 크롬 확장을 이용하여 git project의 보는 방식을 아래처럼 표기해줍니다.

Q6. 인증/인가 정석 프로세스는?

• [현재]
• accessToken만 사용
• “accessToken”을 “localStorage”에 저장
• 요청 시
• accessToken을 header에 보내줌
• 새로고침/페이지 이동 시
• 매번 accessToken 유효성 검사 API call
• 실패(만료)시 login페이지로 redirect
 

• [Goal]
• accessToken, refreshToken, cookie 사용
• “accessToken”은 “전역상태”로, “refreshToken”은 “쿠키”에 저장
• 요청 시
• 위와 동일
• 새로고침/페이지 이동 시
• 매번 refreshToken으로 새로운 accessToken 발급 API call
• 403으로 만료시, axios.intercepter.response에서 accessToken 새로 발급
• accessToken 자체를 localStorage에도, cookie에도 태우지 않는다는 보안상 강점
 

• [궁금/의문]
• 현업에서의 개발편의성과 보안과의 타협을 어느정도 하는지?
• accessToken의 선호 저장 위치는 어떠한가요?
• localStorage 저장, cookie 저장, 전역상태 저장

Q7. 백엔드와의 소통을 할 때, 어떤 문서를 중심으로 소통하나요?

• 이번 프로젝트에, 유저스토리, API명세서, 이슈페이지 각각의 정보변경이 동기화 되지 않아, 소통비용이 커지는 문제 있었음..
• 실제 개발 시 API 명세서는 많이 쓰는 것으로 알고 있고, ”유저스토리” 문서도 다음과 같이 많이 사용하는 지 궁금합니당.