Next.js의 fetch는 requiest Memoization과 data Memoization를 이용해서 사용하는 것으로 이해했습니다. header랑 body를 보내서 api에 재 요청 하지않고 캐싱하는 것을 확인 했는데요 만약에 useQueryhook을 사용한다고 가정하면, useQuery 도 데이터 캐싱기능을 staleTime 등으로 핸들링 할 수 있기에 Next.js의 fetch 캐싱기능을 꺼야 적절할까요? "no-cache"를 해서 useQuery의 캐싱기능만 이용하는 것이 간결하고 시점을 통일 할 수 있을 것 같아서 질문드립니다.
안녕하세요. 좋은 강의 잘 수강하고 있습니다! 강의를 듣던 중 궁금한게 있어 질문드립니다. 정적 사이트 생성 (SSG)는 빌드 타임에 데이터를 서버로 요청하고 받아온 후 렌더링을 미리 해둔다고 이해했는데, 이렇게 되면 사용자가 페이지를 요청한 시점에는 서버의 데이터가 달라졌을 수 있는게 아닌가 하는 의문이 남습니다. 또한 이렇게 된다면 서버의 데이터가 변경될 때마다 매 번 프로젝트를 새로 빌드해야하는 것일까요? 제가 잘못 이해한 부분이 있는지 궁금합니다.
Next.js는 오직 초기 접속시에만 html 파일을 불러와 Hydration 하고 그 이후의 페이지 이동은 리액트의 CSR 방식으로 처리된다고 알고 있습니다. 그런데 Page Router 에서 getServerSideProps 를 사용할 때 매 요청마다 사전 렌더링을 통해 html을 생성하는 것으로 알고 있습니다. 그러면 초기 접속이 아니더라도, getServerSideProps 를 사용한 페이지로 이동하면 Next 서버에서 클라이언트에게 html을 응답해주는 건가요? 서버로부터 html을 응답받는 것이 맞다면 어떻게 깜빡임 없이 화면 전환이 자연스럽게 되는지, 그리고 이렇게 되면 페이지 이동이 리액트의 CSR 방식으로 처리된다고 말할 수 없는건지 궁금합니다 😭 서버로부터 html을 응답받는 것이 아니라면, 클라이언트에서 어떤 값을 서버로부터 받아 렌더링을 하는건지 궁금합니다. getStaticProps 를 사용할 때와 유사하게 json 파일이 생성되어서 이 json 파일을 클라이언트에게 응답해주는 건가요?
서버 컴포넌트에서 클라이언트 컴포넌트에 직렬화 되지 않는 props는 전달 할 수 없다 RSC payload: RSC 렌더링 결과 + 연결된 클라이언트 컴포넌트 위치 + 서버 -> 클라이언트 컴포넌트에 전달하는 props 값 q1. 사전 렌더링 과정에서 서버 컴포넌트를 직렬화 할 때, 여기에 서버 -> 클라이언트 컴포넌트로 전달하는 props 값이 포함되는데 이 값이 함수이면 직렬화 할 수 없기 때문에 props에 함수를 사용할 수 없는 건가요?? q2. 서버->서버, 클라이언트->클라이언트 props는 RSC payload와(직렬화) 관계 없기 때문에 props에 함수 사용이 가능한 건가요??
예를들면 헤더컴포넌트에서 실시간으로 현재 시간을 보여주고싶은 경우가 있다면 헤더 컴포넌트는 모든 페이지에서 보여지는 레이아웃이기때문에 클라이언트 라우터 캐시가 되어서 제가 새로고침을 하는게 아니라면 모든 페이지에서 시간이 멈춰있다는건데 해당 기능을 구현하기 위해서 클라이언트 라우터 캐시를 사용안할수는없나요?
안녕하세요 Next.js 강의를 잘 보고 있습니다. Next.js 장단점 내용을 보고 궁금한 점이 생겨서 질문드립니다. 1. 8:59초에 서버에서 모든 컴포넌트를 사전 렌더링을 한다고 말씀하셨는데, 작성한 모든 컴포넌트 의 HTML을 서버에 생성해놓는다는 의미인가요? 그렇다면 그 HTML을 받아서 브라우저가 파싱할 때, 서버로부터 받는 스크립트는 해당 컴포넌트의 관련된 로직의 js 파일을 받아오는건가요? 이 동작까지 Next.js에서 담당해주는건가요..? 사용자의 접속 요청이 들어왔을 때, FCP는 빠르겠지만 이 과정에서 서버에서 모든 컴포넌트의 사전 렌더링이 진행되고, 하이드레이션 과정까지 있습니다. 전처리 작업은 늘어난 것 같고, 사용자의 인터렉션이 불가한 지점까지 있는데 이 부분은 어떻게 핸들링하는지와 과연 FCP가 단축된게 장점이라고 할 수 있는지 궁금합니다. 해소가 안되는 부분들이 계속 생기는데, 영상을 계속 보다보면 뒤에서 다 설명을 해주시는 부분들일까요...?
안녕하세요 선생님! 해당 수업에서 On-Demand-ISR을 적용하기 위해 page/api/revalidate.ts 파일에 재 생성을 요청하는 handler 함수를 정의를 했습니다. // 강의에서 작성한 handler 코드 export default async function handler( req: NextApiRequest, res: NextApiResponse ) { try { // 인덱스 페이지를 요청받을 때 revalidate 되도록 하기 await res.revalidate("/"); // 재 생성이 잘 완료되었다는 걸 리턴함 return res.json({ revalidate: true }); } catch (err) { // 재생성 실패 했을 떄 실행할 코드 res.status(500).send("실패"); console.error(err); } } 현재 강의에서는 직접 localhost:3000/api/revalidate 를 입력해 수동으로 페이지를 재 생성했는데, 만약 인덱스 페이지 접속할 때마다 자동으로 페이지를 재 생성하고 싶으면 useEffect 훅을 사용하면 될까요? 아래는 제가 작성한 코드입니다! useEffect(() => { fetch("/api/revalidate") .then((res) => res.json()) .then((data) => { if (data.revalidate) { console.log("페이지가 성공적으로 재생 성되었습니다."); } }); }, []);
리액트 쿼리를 사용하면 결국 client side fetching이 됩니다. nextjs13부터 server side fetching이 가능해지고 suspense를 활용한 data streaming은 데이터펫칭에서 새로운 패러다임을 제시했다고 생각합니다. 굳이 리액트 쿼리를 사용할 이유가 있을까요?
On-Demand ISR 사전 렌더링 방식을 보면서 현재 대부분의 SSR로 구현 되어 있는 어플리케이션을 좀 더 최적화 할 수 있겠다는 생각을 했습니다! 여기서 질문은 API Router를 생성해서 revalidate할 경로를 작성해서 해당 경로의 페이지를 On-Demand ISR 처리되도록 구현해주셨는데요..! 실제로 비지니스 로직을 작성할 때는 많은 페이지들이 존재하는데, 이럴때는 API Router에서 "/" 인덱스 페이지 경로를 하드코딩한 부분을 동적으로 받을 수 있게 처리해서 백엔드 서버와 통신 시, 정상응답을 받았을 때, 해당 API Router를 호출하게 하면 되는걸까요..?! 추가로, 페이징 기능 같은 페이지가 있는 경우에는 어떤식으로 On-Demand ISR을 적용하는지도 궁금합니다..!! 바쁘시겠지만 답변 해주시면 감사하겠습니다 😀 🚨 아래의 가이드라인을 꼭 읽고 질문을 올려주시기 바랍니다 🚨 질문 하시기 전에 꼭 확인해주세요 - 질문 전 구글에 먼저 검색해보세요 (답변을 기다리는 시간을 아낄 수 있습니다) - 코드에 오타가 없는지 면밀히 체크해보세요 (Date와 Data를 많이 헷갈리십니다) - 이전에 올린 질문에 달린 답변들에 꼭 반응해주세요 (질문에 대한 답변만 받으시고 쌩 가시면 속상해요 😢 ) 질문 하실때 꼭 확인하세요 - 제목만 보고도 무슨 문제가 있는지 대충 알 수 있도록 자세한 제목을 정해주세요 (단순 단어 X) - 질문의 배경정보를 제공해주세요 (이 문제가 언제 어떻게 발생했고 어디까지 시도해보셨는지) - 문제를 재현하도록 코드샌드박스나 깃허브 링크로 전달해주세요 (프로젝트 코드에서 문제가 발생할 경우) - 답변이 달렸다면 꼭 확인하고 반응을 남겨주세요 - 강의의 몇 분 몇 초 관련 질문인지 알려주세요! - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
레이아웃 컴포넌트의 경우 여러 페이지에 공통적으로 들어가야 하는 것이기 때문에, _app.tsx에 넣어야 하는 것은 이해했습니다. 그리고 모든 페이지에 들어가는 레이아웃이 아닌 특정 페이지만 들어가는 레이아웃의 경우에 정환님 같은 경우에는 getLayout이라는 메서드를 해당 레이아웃을 필요로 하는 페이지 컴포넌트 함수에 메서드로 주시고 _app.tsx에서는 그 메서드를 불러오게끔 하셨는데요. 제가 머리가 나빠서인지는 모르겠지만, 뭔가 이런 메서드로 레이아웃을 관리하니까 이해하기 어렵고 뭔가 직관적으로 다가오는 느낌이 없어서 힘들더라구요.. 그래서 그냥 router와 if문을 이용해서 특정 페이지의 경우에만 searchable 레이아웃이 나오게 하고, 아닌 경우에는 그냥 페이지를 리턴하도록 하는 게 저한테는 뭔가 더 직관적..? 으로 다가오는데 이런 식으로 사용해도 되는지 궁금해서 여쭈어봅니다.. (코드는 밑에 같이 써놓았습니다!) export default function App({ Component, pageProps }: AppProps) { const router = useRouter(); const isSearchableLayoutPage = router.pathname === '/' || router.pathname === '/search'; return ( <GlobalLayout> {isSearchableLayoutPage ? ( <SearchableLayout> <Component {...pageProps} /> </SearchableLayout> ) : ( <Component {...pageProps} /> )} </GlobalLayout> ); }
