[FE] 로그인 상태라면 행사 생성시 로그인 페이지를 띄우지 않음 #857
Conversation
Test Results135 tests 135 ✅ 7s ⏱️ Results for commit df6b79f. |
| <Outlet /> | ||
| </AmplitudeInitializer> | ||
| <ErrorCatcher> | ||
| <QueryClientBoundary> |
There was a problem hiding this comment.
요구 사항이 변경되어서 랜딩 페이지에서 api 호출이 필요하게 되었으므로 다시 돌려놓는 것이 옳다고 생각합니다.
랜딩 페이지 진입 속도 증가 vs 정산 시작하기 버튼 누를 때 메인에 오래 머물기 어떤 것이 더 치명적일 지 생각했을 때 저도 후자라고 생각하기 때문이에요
client/src/apis/request/auth.ts
Outdated
| @@ -42,3 +44,11 @@ export const requestGetKakaoLogin = async (code: string) => { | |||
|
|
|||
| return null; | |||
| }; | |||
|
|
|||
| // 아직 안나온 api라 임의로 두었음 | |||
There was a problem hiding this comment.
저는 이거 실제 api 요청했을 때 정상 응답을 받았어요! 이를 확인한 후에 기능 개발을 완료해서 pr을 올려놨었는데, 혹시 다른 문제가 있었나요?
There was a problem hiding this comment.
지금 dev 서버가 없어졌죠..? 그래서 그런 것 같네용. prod로 하니까 잘 됩니다..ㅋㅎㅎ
| @@ -8,6 +8,7 @@ const QUERY_KEYS = { | |||
| images: 'images', | |||
| kakaoClientId: 'kakao-client-id', | |||
| kakaoLogin: 'kakao-login', | |||
| userInfo: 'user-info', | |||
There was a problem hiding this comment.
저랑 이 내용 겹칠 것 같아서 충돌 잘 해결해봐요!
| http.get(`${MOCK_API_PREFIX}/api/users/mine`, () => { | ||
| return HttpResponse.json( | ||
| { | ||
| nickname: '크리스마스', |
There was a problem hiding this comment.
진짜 크리스마스가 얼마 남지 않았네요;; 벌써;;;;
There was a problem hiding this comment.
All I Want For Christmas Is You~~~
| export type UserInfo = BankAccount & { | ||
| nickname: string; | ||
| isGuest: boolean; | ||
| profileImage: string; | ||
| }; |
There was a problem hiding this comment.
웨디~!~! 바쁠텐데 고생 많았어요.
코드를 확인해 봤는데, 구현이 잘못되어 있는 것 같아요!
메인페이지에서 user/mine api의 isGuest 요청 결과를 사용해서 login 화면 및 생성 화면으로 이동하는 로직이 있는데,
이 isGuest 는 카카오로그인이면 false, 비회원로그인이면 true로 반환되어요.
그래서 현재 웨디가 구현한 부분을 실행해보면 아래와 같아요.
- 카카오 로그인
- 행사생성
- 홈으로 이동 (/api/user/mine API 호출 -> isGuest : false)
- 정산 시작하기 버튼 클릭
- 로그인 페이지로 이동
반면, 카카오 로그인이 아니라 비회원 생성을 한다면,
- 비회원 로그인
- 행사생성
- 홈으로 이동 (/api/user/mine API 호출 -> isGuest : true)
- 정산 시작하기 버튼 클릭
- 행사 생성 페이지로 이동
처럼 작동해요!
혹시 제가 애초에 처음 구현 의도를 제대로 파악하지 못한거였다면 미안해요...
제가 느끼기에는 카카오로그인, 비회원로그인 모두 로그인 되어 있는 정보가 있다면 로그인 창을 건너뛰는게 맞다고 생각했어요!
| @@ -1,3 +1,4 @@ | |||
| // TODO: (@weadie) 반복되서 쓰이는 이 api/events가 추후 수정 가능성이 있어서 일단 편집하기 편하게 이 변수를 재사용하도록 했습니다. | |||
| export const USER_API_PREFIX = '/api/events'; | |||
| export const ADMIN_API_PREFIX = '/api/admin/events'; | |||
| export const MEMBER_API_PREFIX = '/api/users'; | |||
There was a problem hiding this comment.
순간 제가 추가해둔 코드가 반영된 줄 알고 확인하고 와써욪.. 동일한 생각을 하셨군여
There was a problem hiding this comment.
ㅋㅋㅋㅋㅋㅋㅋㅋ역시 다 똑같은 생각을 하고있었습니다
| @@ -42,3 +44,11 @@ export const requestGetKakaoLogin = async (code: string) => { | |||
|
|
|||
| return null; | |||
| }; | |||
|
|
|||
| export const requestGetUserInfo = async () => { | |||
There was a problem hiding this comment.
저는 user와 관련된 부분은 user.ts 파일을 생성하여 작성해줬는데요! 이 코드 또한 user.ts 파일로 가도 좋을 것 같네용!
merge할 때 같이 논의해봐요~!
There was a problem hiding this comment.
오 좋네요 API PREFIX도 나눠두었으니까 파일을 나눠도 괜찮겠습니다
| @@ -47,7 +47,7 @@ export type RequestPatchUser = Partial<User>; | |||
|
|
|||
| export const requestPatchUser = async (args: RequestPatchUser) => { | |||
There was a problem hiding this comment.
이 부분 또한 저도 웨디와 동일하게 변경해줬어요!
다만 해당 코드도 event.ts 파일보다 user.ts 파일에 이동되는건 어떨지 논의해봐요!
|
토다리 코멘트 남겨준 부분을 반영완료했습니다! 고마워요!!~ 비회원으로 계속하기는 사실 비회원 로그인이 아니라 행사를 위한 일회용 회원이기 떄문에 로그인 페이지가 떠야 된다고 생각했어요. 그래서 isGuest가 false인 경우만 로그인 페이지가 안뜨도록 하였고, 그 외 경우에는 전부 로그인 페이지가 뜨도록 했습니다! 그리고 추가적으로 api실패시 전역 에러 핸들러가 동작해서 토스트가 뜨고 있었어요. 그래서 에러 핸들러 구독 해제를 할 수 있도록 구현을 조금 수정했습니다. 이슈를 나누려다가 너무 작은 일거리라 그냥 합쳐서 했어요..ㅎㅎ |
pr 수정 내용
구현 사항
1. isGuest가 반대로 되어 로그인 상황일 때 로그인 페이지가 뜨고, 로그인 상황이 아닐 때 로그인 페이지가 안뜨는 문제를 해결했습니다.
2. MainPage에서 호출하는 회원 정보 확인 api에서 오류 토스트가 뜨는 문제를 해결했습니다.
이 pr이 반영된다면 로그인 상태가 아닌 채로 MainPage에 진입하면
로그인 정보를 확인하는 api에서 401 쿠키없음 에러를 받습니다. 그리고 이 에러가 에러 핸들러에서 처리가 되기 때문에 "로그인해야 이용할 수 있습니다"라고 토스트가 뜨는 문제가 있었습니다.로그인 정보를 확인하는 api에서는 쿠키가 없을 때 쿠키 없음 에러를 뱉지 않고 200에 리스폰스 바디에 에러코드로 분기해달라고 요청할 수도 있었으나, 백엔드 설계를 많이 바꿔야할 것 같아 다른 방법을 생각했습니다.해당 api에서 에러가 발생하는 경우는 쿠키가 없을 때 즉 비회원인 경우입니다. 에러의 발생 여부로 회원, 비회원을 판단하는 것입니다. 따라서 디폴트로 수행되는 에러 핸들러의 동작을 이 api에서는 막아줘야 합니다.
그래서 커스텀 에러 객체의 errorHandlingStrategy에 'unsubscribe' 속성을 유니온에 추가하였고 이 속성을 사용하는 api일 경우 에러 핸들링이 되지 않도록 했습니다.
3. initialData와 initialDataUpdatedAt 을 사용해 회원 정보 확인 api에서 오류가 떴을 때도 정상적으로 플로우가 수행되도록 했습니다.
에러 핸들링이 무시되었다면 기본적으로 api의 반환 값(캐싱되는 값)이 null로 남아있습니다. 그래서 initialData를 주어 에러가 났을 때에는 initialData를 주어 사용하고 에러가 안나서 무사히 fetch가 되었을 때는 받아온 정보의 isGuest를 사용하여 로그인 페이지 유무를 결정하도록 했습니다.
이때 initialData를 계속 사용하지 않도록 하려면 즉, 신선한 데이터를 사용하도록 api를 호출하도록 하려면 useQuery의
initialDataUpdatedAt이라는 속성을 지정해주어야 합니다.initialDataUpdatedAt은 간단하게 말하면 이 initialData가 언제 캐시되었느냐(fetch되었느냐)를 말합니다. 그래서 0으로 지정하면 이 initialData가 기본적으로 적용되있는 staleTime과 비교해 다시 fetch됩니다. 즉 initialData를 사용하는 경우인로그인 정보를 확인하는 api에서 오류가 났을 때만 매번 다시 요청을 하고, initialData가 아닌 실제 데이터가 캐싱되어있을 때는 기본적으로 적용되어있는 staleTime을 사용하게 됩니다.staleTime을 0을 주는 방법도 있었으나 그러면 해당 api를 사용하는 다른 곳에서 캐싱 이득을 보지 못하기 때문에 initialDataUpdatedAt을 사용해봤습니다.
issue
구현 목적
최근에 로그인 했다면 다시 로그인 페이지를 띄우지 않고 바로 행사 생성을 할 수 있도록 합니다.
구현 사항
로그인 여부는 쿠키에 저장됩니다.
다만 쿠키를 클라이언트가 확인할 수 없기 때문에, 로그인 여부가 포함된
회원 정보 확인 api를 호출해 로그인 여부를 확인합니다.회원 정보 확인 api를 호출하는 시점은 "정산 시작하기"버튼을 눌렀을때로 하려다가, api 호출이 오래걸리면 MainPage에 계속 머물러있는게 이상할 것 같아서 MainPage 진입 시 호출하도록 했습니다.이를 위해 현재 MainPage에서 tanstackquery호출이 안되도록 분리해놓았던 것을 예전대로 롤백시켜놓았습니다.
그리고 현재 회원 정보 확인 api가 나와있지 않은 상황이므로 msw를 사용하여 테스트했습니다.