react query 공식 문서에 따르면 dehydratestate를 반환하면 useQuery를 이용해 바로 data를 이용할 수 있다고 하는데, typescript의 타입 체커에 의해서 useQuery가 반환한 데이터가 undefined인 경우가 있어, useResource 안에서 이에 대한 처리를 어떻게 하셨는지 궁금하네요 ㅎㅎ
컴포넌트 내부에서 API를 호출하는 로직을 적용하면 해당 컴포넌트는 API에 종속하는 형태가 되기에 다른 페이지에서 재활용 할 수가 없지 않나요? 물론 비즈니스 컴포넌트가 다른 페이지에서 재사용 될 확률이 얼마나 되겠냐만은 재활용 가능한 컴포넌트라는 정체성을 잃지 않기 위해 데이터를 페이지에서 모조리 관리하는 방식을 추구합니다. 하지만 이 방법을 쓰니 영상에서 처럼 Props Drilling 현상은 어떻게 할 수가 없더라구요.
개발자가 아니지만 문제를 푸는 방식과 목적이 사용자편의기반이라는 점을 항상 토스를 보면서 생각합니다~! 잘보고갑니다
크 멋지십니다
많이 배워갑니다
안녕하세요 도환님 영상 잘 봤습니다!
nextjs 데브 환경에서 라우팅시 페이지를 새로 빌드하게되어 느려서 답답했는데 이러한 이슈가 없으셨을까요? 있어서 개선했다면 개선하신 방법들 알려주실수 있을까요?
react query 공식 문서에 따르면 dehydratestate를 반환하면 useQuery를 이용해 바로 data를 이용할 수 있다고 하는데, typescript의 타입 체커에 의해서 useQuery가 반환한 데이터가 undefined인 경우가 있어, useResource 안에서 이에 대한 처리를 어떻게 하셨는지 궁금하네요 ㅎㅎ
저도 너무 궁금해요!
컴포넌트 내부에서 API를 호출하는 로직을 적용하면 해당 컴포넌트는 API에 종속하는 형태가 되기에 다른 페이지에서 재활용 할 수가 없지 않나요?
물론 비즈니스 컴포넌트가 다른 페이지에서 재사용 될 확률이 얼마나 되겠냐만은 재활용 가능한 컴포넌트라는 정체성을 잃지 않기 위해 데이터를 페이지에서 모조리 관리하는 방식을 추구합니다.
하지만 이 방법을 쓰니 영상에서 처럼 Props Drilling 현상은 어떻게 할 수가 없더라구요.
감사합니다
그럼 이벤트에 필요한 js는 어떻게 가지고 오는 건가요? 애초에 html에 스크립트 태그로 넣어서 보내는 건가요? 아니면 서버 사이드 렌더링 이후에 다시 js를 요청하는 건가요?
@김도환 감사합니다!
발표에서는 ui를 그리는 2번까지만 말씀하신거고, 하이드레이션 과정에 대해서는 언급하신게 없는거죠?
queryClient랑 getInitialProps의 context를 저런 식으로 사용할 수 있을 줄은 몰랐네요 기가 맥힙니다
저희 팀은 queryClient의 prefetchQuery를 활용해서 SSR시 데이터 핸들링을 하고 있는데요. 해당 방식도 논의가 되었었나요? 토스팀에서의 구현 방식도 굉장히 흥미롭네요
저도 이 부분이 궁금하네요. 아니면 useResource 관련 로직 내부에서 이미 포함하고 있을지도?!
저도 궁금해요!!
부어엉
저희쪽에 적용할 수 있으면 참 좋겠습니다. 많이 배워갑니다~