[OD-114] ProfileViewer 페이지 api 연동 #77
Conversation
|
굿잡 ~~~~ |
src/pages/ProfileViewer/index.tsx
Outdated
| const [userInfoResponse, postsResponse] = await Promise.all([ | ||
| getUserInfoApi(userIdAsNumber), | ||
| getUserPostListApi(1, 10, userIdAsNumber), | ||
| ]); |
There was a problem hiding this comment.
유저 정보와 게시글 정보를 한번에 받으면 안 될 것 같아요!
사용자 게시글이 500개가 된다고 가정하면, 이것들을 한 번에 불러오려면 서버에서 데이터를 보내주는 데 시간이 너무 오래 걸리기 때문에 페이지네이션을 한 것입니다!! 따라서 10개씩 받아오겠다 가정하면 getUserPostListApi(postPage.current, 10, userIdAsNumber) 같은 형태로 작성해서 postPage.current를 계속해서 업데이트 해 주어야 해용
인스타에서 특정 사용자 계정에 들어가서 스크롤을 해 보면 12개씩 조회하는 걸 알 수 있습니다! 그 페이징을 버튼이 아닌 스크롤로 감지하여 자동으로 다음 정보를 조회하도록 하는 게 스크롤 페이징이고, 스크롤을 감지하여 getUserPostListApi를 여러 번 호출해야 하기 때문에 둘은 분리가 되어야 하겠죵?
src/components/PostBase/LikeCommentBottomSheetContent/index.tsx에 IntersectionObserver를 사용한 무한스크롤이 구현되어 있으니 참고해서 수정하시면 될 것 같아요~~
그런데 근본적인 의문이 드는 점은 userInfo를 따로 받아오는 이유가 있나요? userPostListApi에서 오는 유저정보로는 부족한 부분이 있을까요?
There was a problem hiding this comment.
추가로 userDetails를 localstorage에 저장하는 이유가 궁금해요!
There was a problem hiding this comment.
getPostListApi를 사용한 스크롤페이징 -> 말씀해 주신 부분 참고해서 수정하겠습니다!!
사용자 정보 조회를 하는 이유는 게시글 조회하기 api에는 없는 bio와 isFriend 상태를 받아오기 위함이었습니답
전에 UserProfile 부분을 공통 컴포넌트화 하며 이곳에서 유저 정보를 받아올지 아니면 UserProfile 컴포넌트를 사용하는 컴포넌트에서 각각 받아올지를 고민했었는데
제 프로필 조회 페이지에서는 어차피 유저 정보 조회의 응답 중 isFriend 값이 필요했었어서 그냥 프로필 조회 페이지에서 api를 호출하는 거로 결정했었는데...
코멘트를 받고 곰곰히 생각해 보니 전역 상태관리를 이용하면 해결되는 문제인 것 같습니다.
UserProfile이 프로필 조회 페이지를 들어가자마자 보여지니 그곳에서 사용자 정보 조회를 한 후 recoil에 저장을 하고 그걸 UserInfo에서 필요한 값을 꺼내 (isFriend나 bio 등) 쓰면 되겠군요!!
로컬스토리지도 전에는 그저... 새로 고침 시 UI가 유지 될 때는 로컬스토리지를 써라!! 라고 예~~ 전에 배운 게 생각이 나 초기에 프로젝트 돌입 시 그냥 로컬에 저장하는 것부터 시작했던 것 같습니다.
근데 이것도 recoil을 사용하고 페이지에 들어올 때마다 사용자 조회 api를 호출하니 이럴 필요 없는 것 같네용
그리고 게시글 조회랑 유저 정보 조회를 함께 호출해 CombineData를 만든 건 한 번에 불러서 다른 컴포넌트에서 게시글 수를 가져다 쓴다던지 하며 상태의 수를 줄이고 싶었는데 성능 측면에서 안 좋을 것 같네용.
지금 곰곰히... 생각해 본 것인데 어떠신가용
There was a problem hiding this comment.
여기까지가 UserInfo 아닌가용? 저는 isFriend나 bio를 UserInfo에서만 사용한다고 생각했어요!
처음에는 다른 컴포넌트에서 사용해야 한다면 recoil로 관리할 수 있고, 새로고침을 해도 정보가 유지되어야 하면 recoil-persist를 사용하면 될 거라고 생각했는데, 곰곰이 코드를 읽고 나서는 그 정보들이 정작 UserInfo에서만 필요한 것 같아서요!
제가 이해한 대로 UserInfo에서만 isFriend나 bio를 사용한다면 전역으로 관리할 필요가 없어지고, 리렌더링 이슈도 useParams를 이용해 경로에서 userId를 얻어온다면 문제 없을 거라고 생각했습니닷
제가 잘못 생각한 부분이 있을까요?
| if (postsCount === 0) { | ||
| setIsBottomSheetOpen(false); | ||
| handleModalOpen('게시물 등록 후 \n친구 요청을 보낼 수 있어요!'); | ||
| return; | ||
| } |
There was a problem hiding this comment.
이 부분에 대해서 지난번에 예외처리 해야겠다는 얘기가 있었어서 서버쪽에 따로 예외처리 된 바가 있는지 확인해 보시면 좋을 것 같아요!
There was a problem hiding this comment.
서버 쪽에서 따로 예외처리라 함은 응답으로 오는 에러 중 예를 들어 '사용자의 게시물이 없습니다.' 이런 응답을 말씀하시는 거죵???
전에 그냥 들은 바로는 게시물 없으면 막으라고 해서 UserInfo에서 따로 함수를 만들어 체크했었는데... 그럼 서버 쪽에 요청을 해야 하는 거죵...??? (이때 전에 사용자 정보 조회 + 게시글 리스트 조회의 응답을 한번에 조합한 것을 로컬에 넣어서 이런 곳에 꺼내서 썼습니다. 이런 식으로 쓰려고 했던 것... 인데 위의 코멘트대로 수정해야 할 듯 싶어용)
There was a problem hiding this comment.
마자요 만약에 서버 차원에서 게시글이 없는 사용자의 매칭 요청을 막는다면 클라단에서 사용자의 게시글 정보를 조회해서 게시글이 있나 없나 복잡하게 확인할 필요 없이 catch문에서 잡힐 테니까 그게 더 간편할 것 같아요!! 담당 백엔드분께 한번 문의해보세용
There was a problem hiding this comment.
만약 서버에서 예외처리를 하셨다면 userDetails를 받아와서 게시글 개수를 반환하는 checkPostCount를 호출하여 게시글이 없진 않은지 확인할 필요가 없어지겠죠?! userDetails 로직까지 사라진다고 생각하면 코드가 아주 단순해질 것입니다. . .
| <LongButton | ||
| onClick={ | ||
| friend | ||
| ? handleMessageClick | ||
| : () => { | ||
| setIsBottomSheetOpen(true); | ||
| } | ||
| } | ||
| disabled={nickname === '알 수 없음'} | ||
| > | ||
| {friend ? ( | ||
| <StyledText $textTheme={{ style: 'body1-medium' }} color={theme.colors.white}> | ||
| 메세지 보내기 | ||
| </StyledText> | ||
| ) : ( | ||
| <> | ||
| <img src={HeartSvg} alt="heart icon" /> | ||
| <StyledText $textTheme={{ style: 'body1-medium' }} color={theme.colors.white}> | ||
| 친구 신청 | ||
| </StyledText> | ||
| </> | ||
| )} | ||
| </LongButton> |
There was a problem hiding this comment.
friend를 검사하는 로직이 결국 LongButton의 onClick 속성 등과 자식 요소를 결정하는 거니까
friend ? <LongButton ...>메시지 보내기 : <LongButton ...>친구 신청
이런 방식은 어떨까용?... 성능적으로는 큰 차이가 없을 것 같고 결국 가독성 문제인데, 어느 게 더 좋을지 저도 잘 모르겠네요 ㅠㅠ 한번 고려해 주세요!
주요 작업 내용
기타 작업 내용
코드 리뷰 포인트
작업 화면