-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FE] EventLoader하위로 EditAccountPage를 옮겨 데이터를 유지하기 위한 로직을 제거 #877
base: fe-dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생 많았어요 웨디~ 버그를 잡기 위해 어떻게 보면 임시방편으로 버그를 잡아둔 내용이었는데 더 좋은 해결 방안을 연구하고 이를 구현해내는 모습이 너무 멋있어요!!
추가로 이벤트 페이지 속 관리 페이지 내에서 사용하는 퍼널들, 송금 페이지들을 비슷하게 처리해줘도 좋을 것 같아요~
/** | ||
* 이 훅이 하는 일: | ||
* 이벤트 정보 불러오기 + 총액 상태 계산하기 | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
제가 작성했던 방식은 여기서 데이터를 fetch 해두고 하위 컴포넌트에서 캐시된 데이터를 불러와서 사용하는 방식이었어요. 이렇게 바꾸게 되면 여기서 데이터를 fetch 하고 하위 컴포넌트에서 context를 사용해서 값을 불러올 수 있게 될 것 같아요! 하지만 하위에서는 context와 의존성이 생긴다는 제약은 있지만..;;
const location = useLocation(); | ||
const locationState = location.state as BankAccount | null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
오류가 나서 임시 방편으로 이렇게 버그를 해결해두었는데 근본을 잡고 개선점을 찾아 더 좋은 방안으로 바꿔주셔서 감사해요😄 이런 모습 하나하나가 웨디의 큰 장점인 것 같아요~~
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
버그를 해결했다는게 더 유용한거죠!!!! 저는 그냥 숟가락만 얹었을 뿐,,
{ | ||
queryKey: [QUERY_KEYS.allMembers], | ||
queryFn: () => requestGetAllMembers({eventId}), | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저는 이 부분도 논의해보고 싶어요. 이 데이터를 여기서 fetch하는 이유는 순전히 amplitude에 데이터를 보내기 위해서 였어요. 행사 당 평균 인원 수를 확인해보고 싶어서 호출하는 것인데 지금 amplitude에서 이를 확인하고 있지 않아서 빠져도 되지 않을까 하는 생각도 있습니다. 이 내용은 회의 때 이야기해봐도 좋을 것 같아요
@@ -81,31 +81,39 @@ const router = createBrowserRouter([ | |||
path: ROUTER_URLS.event, | |||
element: ( | |||
<Suspense fallback={<EventPageLoading />}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
여기 EditAccountPage에서 EventPageLoading이 보일 때 헤더가 보였다가 사라지는 현상은 아직 해결 안 된 거죠?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
넵 맞습니다. 사실 치명적인 문제는 아니니까 우선순위가 낮을 것 같았어요.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
좋아요~ 일단은 todo로 두고 나중에 고쳐봐요!
issue
구현 목적
useAccount를 다른 컴포넌트에서도 사용할 수 있도록 리펙터링 해야했는데, 이 안에서 location.state를 사용하고 있었습니다.
이 값은 EditAccountPage(useAccount를 사용하고 있음)에 url을 입력해 직접 접근했을 때 EventLoader에서 받아오는 데이터에 접근하지 못해 오류가 발생하기 때문에 사용되었습니다.
EventLoader에서 받아오는 정보를 EditAccountPage에서 사용해야한다면, 해당 페이지를 EventLoader 하위로 옮겨 EventLoader 호출이 선행 되어야 EditAccountPage를 렌더링할 수 있도록 바꾸는 것이 추가적인 로직을 작성하는 것보다 직관적입니다.
구현 사항
path='/evnet'의 router 관계 변경
path='/event'에는 이벤트의 정보(계좌, 행사 명 등)를 호출해 Provider로 데이터를 하위 트리에 뿌리는 EventLoader컴포넌트가 있습니다. 그리고 이 컴포넌트에서 뿌리는 데이터를 EditAccountPage에서도 사용해야하므로 다음과 같이 router 관계를 변경하였습니다.
(가독성을 위해 tab을 여러번 침)
Outlet 중첩으로 outletContext를 유지하는 것보다 context를 사용하는 것이 유지보수에 좋음
이렇게 수정하고 나면 EventLoader(빨간색)와 AdminPage(노란색)의 depth가 2가 되는데요. 이 경우 outletContext로 데이터를 전달해주는 것보단 그냥 context를 이용하는 게 데이터 흐름 이해 코스트를 줄일 수 있으며 유지보수에도 좋을 것이라고 생각되었습니다.
그래서 데이터를 호출하는 EventLoader에서 Provider를 사용해 데이터를 뿌리도록 구현하였습니다.
결과