안녕하세요 강의중에는 fetch를 사용하는데기존에 프로젝트를 진행할때,baseUrl 설정이나 기본 헤더 설정, 인터셉터 및 json 직렬화 등 의 불편함으로 axios를 사용하였었는데next에서 캐싱관련해서 fetch를 확장해서 제공해주기때문에 axios를 사용하지않고 fetch로 사용하는걸까요?

안녕하세요. 제로초 강사님. 수업 그대로 따라가고 있었는데 궁금한 점이 생겨서 질문 드립니다.영상과 동일하게 따라하고 있었고, 질문이 있는 파일 경로는 다음과 같습니다.src\app\(beforeLogin)\@modal\(.)i\flow\login\page.tsx이 때,파일명을 page.tsx --> qwer.tsx로 변경하면 404 에러를 띄웁니다. 혹시나 해서,src\app\(beforeLogin)\i\flow\login\page.tsx의 파일 또한 qwer.tsx로 바뀐 뒤 해당 경로로 들어가려고 하면 똑같이 404 에러를 띄웁니다. src\app\(beforeLogin)\page.tsx 파일의 import Image from "next/image"; import styles from '@/app/page.module.css' import Link from "next/link"; import zlogo from '../../../public/zlogo.png' export default function Home() { return ( <> <div className={styles.left}> <Image src={zlogo} alt="logo"/> </div> <div className={styles.right}> <h1> 지금 일어나고 있는 일 </h1> <h2> 지금 가입하세요 </h2> <Link href="/i/flow/signup" className={styles.signup}> 계정 만들기</Link> <h3> 이미 트위터에 가입하셨나요? </h3> <Link href="/i/flow/login" className={styles.login}> 로그인 </Link> </div> </> ); }에서<Link href="/i/flow/login" className={styles.login}> 로그인 </Link>컴포넌트를 클릭시 제가 원하는 해당 경로의 특정파일명과 매핑할 수 있는 방법이 있나요?? 아니면 하나의 폴더에는 하나의 page.tsx만 존재해야하고, 그 파일 명은 page.tsx가 되야하는 규칙인건가요??

useSelectedLayoutSegment 를 DetailPage 안의 infoData 라는 컴포넌트에서 사용하려하였고,클라이언트 컴포넌트입니다.useSelectedLayoutSegment은 layout.tsx 에서 infoData 를 부를때만 사용할수있는건가요?layout.tsx 에서 infoData 를 불러오면 segment를 잘 가져오고 DetailPage 라는 곳에서 infoData를 사용하면 segment 가 null로만 반환되고있습니다.Layout의 children으로 DetailPage가 들어가고 DetailPage의 children으로 infoData가 들어가는데layout.tsx 에서 직접 컴포넌트를 불러올때만 값을 받아오고 layout의 자식의 자식으로 사용될때에는 왜 값을 가져오지 못하는건지 이해가 안되서 질문드립니다. 

강의 17분 50초 정도에 말씀하신 얇은 복사중에서 왜 이런식으로 복사해야하는지 이해가 잘 되지 않습니다. const shallow = { ...value }; value.pages = { ...value.pages }; value.pages[pageIndex] = [...value.pages[pageIndex]];제가 강의를 보기전 테스트할때는 해당 코드로 작성하였는데 해당 코드는 정상적으로 작동하지 않았습니다 const shallow = { ...value }; shallow.pages = { ...value.pages }; shallow.pages[pageIndex] = [...value.pages[pageIndex]];혹시 왜 첫번째 코드블록처럼 코드를 작성해야하는지 간단하게 설명해주시면 감사하겠습니다

예를들어, 이런 소셜 네트워크 서비스같은 경우에는 useSWR보다, react-query가 다양한 기능을 제공해주어, 적합하다고 생각이 되어집니다. 1 . 단순 데이터만 갖고오는 사이트가 아니라면, 대부분 react-query가 더 좋다고 생각하는데, useSWR은 어떤 서비스에서 주로 채택하면 좋은지에 대해 알고싶습니다. react-query와 useSWR을 혼용해서 사용했을때 더 좋아지는 경우가 있을까요? 어떠한 서비스를 만들때, useSWR, react-query를 선택해야한다면, 어떤 기준으로 판별하는 것이 좋은지에 대해서도 알고 싶습니다. 

CredentialsSignin 에러가 발생합니다.아래의 CredentialsSignin 질문과 같이 redis 재시작,백엔드 서버 재시작, next, node_modules 삭제 후 다시 npm install 후 확인해도 계속 같은 에러가 나옵니다.next[auth][error] CredentialsSignin: Read more at https://errors.authjs.dev#credentialssignin at Module.callback (webpack-internal:///(rsc)/./node_modules/@auth/core/lib/actions/callback/index.js:256:30) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async AuthInternal (webpack-internal:///(rsc)/./node_modules/@auth/core/lib/index.js:65:24) at async Auth (webpack-internal:///(rsc)/./node_modules/@auth/core/index.js:123:29) at async /Users/mac/Documents/next14/node_modules/next/dist/compiled/next-server/app-route.runtime.dev.js:6:63251백엔드[Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [WebSocketsController] EventsGateway subscribed to the "test" message +22ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [WebSocketsController] EventsGateway subscribed to the "sendMessage" message +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [WebSocketsController] EventsGateway subscribed to the "login" message +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RoutesResolver] AppController {/}: +2ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RoutesResolver] ApiController {/api}: +1ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/login, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/logIn, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/logout, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/logOut, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/user, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/decode, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RoutesResolver] HashtagsController {/api/hashtags}: +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/hashtags, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/hashtags, GET} route +1ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/hashtags/trends, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/hashtags/:id, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/hashtags/:id, PATCH} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/hashtags/:id, DELETE} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RoutesResolver] UsersController {/api/users}: +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/followRecommends, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id/posts, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id, PATCH} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id, DELETE} route +1ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id/follow, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id/follow, DELETE} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id/rooms, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/users/:id/rooms/:roomId, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RoutesResolver] PostsController {/api/posts}: +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/recommends, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/followings, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id/heart, DELETE} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id/heart, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id, DELETE} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id/reposts, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id/reposts, DELETE} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id/comments, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id/comments, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/posts/:id/photos/:imageId, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RoutesResolver] MessagesController {/api/messages}: +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/messages, POST} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/messages, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/messages/:id, GET} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/messages/:id, PATCH} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [RouterExplorer] Mapped {/api/messages/:id, DELETE} route +0ms [Nest] 6106 - 01/01/2024, 3:07:18 PM LOG [NestApplication] Nest application successfully started +2ms redis connected test 12345 test 123125 test sadfasf test zcxv 

command + p (or ctrl+p) 누르면 나오는 서치창에내가 만든 파일명을 입력하면 해당 파일을 찾을 수 있습니다.어느 소통창구로 알려드려야 할지 몰라서 여기다 적어요

(afterLogin)의 layout.tsx에서 35번째 주석부분 children이요여기 children에 각 폴더 page.tsx, layout.tsx이 들어가는건가요??여기 35번 줄 children 주석풀고 실행해보면이런 오류 뜨는데 왜 이런지 알 수 있을까요??

안녕하세요 제로초님! 강의 즐겁게 듣고 있습니다. 깃허브의 코드를 보면 main.module.css에서 container를 잡을 때 width와 heigth로 dvw, dvh단위를 사용하시고다른 부분(login.module.css 와 signup.module.css)에서는 vw를 사용하시고 있어서요.  dvw를 사용하시는 경우와 vw를 사용하시는 경우의 차이가 궁금합니다.  

chat gpt가 "Next.js에서 라우팅을 설정할 때 pages 폴더는 매우 중요한 역할을 합니다. 이 폴더는 Next.js 프레임워크가 자동으로 URL 경로와 매핑하는 라우팅 시스템의 핵심입니다. 따라서, 기본적으로 라우팅을 위한 파일들은 pages 폴더 내에 위치해야 합니다.그러나, 여러분이 제시한 구조처럼 src/app 디렉토리 안에 페이지 컴포넌트를 배치하는 것도 가능합니다. 이 경우, Next.js의 기본 라우팅 규칙을 따르지 않기 때문에, 명시적으로 라우팅 로직을 정의해야 합니다. 예를 들어, Next.js의 Custom Server 기능을 사용하여 Express.js 또는 다른 Node.js 서버 프레임워크와 함께 라우팅 로직을 직접 작성할 수 있습니다.이렇게 하면, src/app 폴더 내의 파일 구조를 사용하여 원하는 URL 경로와 매핑할 수 있습니다. 하지만 이 방법은 Next.js의 자동 정적 최적화, 파일 기반 라우팅 등과 같은 기본 제공 기능들을 직접 관리해야 하는 추가적인 작업이 필요합니다."라고 하는데 그럼 저희는 이번 강의에서 page폴더를 넣지 않았으니 next.js의 폴더 구조 라우팅 시스템을 활용하지 않고 직접 라우팅 로직을 작성할 것이라는 건가요?

[제로초 강좌 질문 필독 사항입니다]질문에는 여러분에게 도움이 되는 질문과 도움이 되지 않는 질문이 있습니다.도움이 되는 질문을 하는 방법을 알려드립니다.https://www.youtube.com/watch?v=PUKOWrOuC0c0. 숫자 0부터 시작한 이유는 1보다 더 중요한 것이기 때문입니다. 에러가 났을 때 해결을 하는 게 중요한 게 아닙니다. 왜 여러분은 해결을 못 하고 저는 해결을 하는지, 어디서 힌트를 얻은 것이고 어떻게 해결한 건지 그걸 알아가셔야 합니다. 그렇지 못한 질문은 무의미한 질문입니다.1. 에러 메시지를 올리기 전에 반드시 스스로 번역을 해야 합니다. 번역기 요즘 잘 되어 있습니다. 에러 메시지가 에러 해결 단서의 90%를 차지합니다. 한글로 번역만 해도 대부분 풀립니다. 그냥 에러메시지를 올리고(심지어 안 올리는 분도 있습니다. 저는 독심술사가 아닙니다) 해결해달라고 하시면 아무런 도움이 안 됩니다.2. 에러 메시지를 잘라서 올리지 않아야 합니다. 입문자일수록 에러메시지에서 어떤 부분이 가장 중요한 부분인지 모르실 겁니다. 그러니 통째로 올리셔야 합니다.3. 코드도 같이 올려주세요. 다만 코드 전체를 다 올리거나, 깃헙 주소만 띡 던지지는 마세요. 여러분이 "가장" 의심스럽다고 생각하는 코드를 올려주세요.4. 이 강좌를 바탕으로 여러분이 응용을 해보다가 막히는 부분, 여러 개의 선택지 중에서 조언이 필요한 부분, 제 경험이 궁금한 부분에 대한 질문은 대환영입니다. 다만 여러분의 회사 일은 질문하지 마세요.5. 강좌 하나 끝날 때마다 남의 질문들을 읽어보세요. 여러분이 곧 만나게 될 에러들입니다.6. 위에 적은 내용을 명심하지 않으시면 백날 강좌를 봐도(제 강좌가 아니더라도) 실력이 늘지 않고 그냥 코딩쇼 관람 및 한컴타자연습을 한 셈이 될 겁니다. 안녕하세요 로초님! 강의 잘 보고 있습니다. 다름 아니라 position:fixed;는 뷰포트를 기준으로 레이아웃을 배치하게 만드는 속성값이라서, top, left, bottom, right 중 하나 이상을 써야 레이아웃이 정상적으로 된다고 알고 있는데, (afterLogin)/layout.module.tsx의 .leftSectionFixed와 .search에서는 top같은 거 없이도 의도한 대로(sticky처럼?) 기능하는 이유가 무엇인지 궁금합니다. 옛날에 제가 다른 프로젝트 만들었을 때는 fixed랑 top을 같이 안 써서 헤맨 적이 있어서, 앞으로는 top을 꼭 같이 써야겠다고 알고 있었고,지금 구글링 해서 fixed의 사용법을 찾아봐도 다들 top같은 걸 써야 한다고 말하고 있어서, 혹시 다른 사용법이 있는 건지 궁금해서 여쭈어봅니다. 답변 기다리겠습니다. 감사합니다:)

특별한 이유가 있나요?

선생님의 설명 덕분에 클라이언트 컴포넌트에서도 Server Action을 활용하는 방법을 알게 되었습니다. 하지만 몇가지 의문이 있는 상태입니다. ㅜㅜServer Action이라는 것이 클라이언트 컴포넌트에서 직접 DB에 접근하거나 별도의 브라우저에서 요청하지 않더라도 서버에 요청을 보내서 Prerendering 하는 방식이 맞을까요?그러면 보안 상의 장점도 가질 수 있고, 속도에도 개선이 생기는게 맞을까요?클라이언트 컴포넌트에서 Server Action을 사용하게 된다면 기존의 Server Action의 장점이 없어지는 것 같은데 사용하는 이유가 단순히 강의에서의 설명을 위함이신지 아니면 별도의 장점이 있으셔서 강의에 넣으실 계획을 하신 건지 궁금해서 질문남깁니다!

제가 이해한 것이 맞는지 확인차 질문 남기게 되었습니다!MSW의 경우, service worker가 브라우저의 요청을 뺏어서 browser.ts로 요청을 전달하는 게 맞을까요?그렇다면 http.ts같은 경우는 서버 컴포넌트에서 서버로 요청을 보낼 때는 next 서버에서 요청을 보내고 난뒤의 데이터를 가지고 서버에서 미리 렌더링하기 때문에 이 요청을 mocking하기 위해 만들어두신 개념이 맞을까요?

안녕하세요! 강의 중간에 generateMetadata 를 사용하는 부분에서 왜 서버 api로 분리를 했는지에 대해 의문이 생겨서 질문드립니다.generateMetadata 에 사용할 getSinglePost 함수는 원래 아래와 같은 코드로 작성되어있었습니다.  여기서 generateMetadata 를 구현하실때, 기존의 getSinglePost 를 사용하시지 않고, getSinglePostServer 를 사용하셨는데 혹시 왜 이렇게 서버 API로 분리를 하셨는지 알 수 있을 까요?  처음에는generateMetadata 는 서버 환경에서 진행이 되기 때문에 서버에서 돌아가는 api를 작성해야 한다그렇기 때문에 credentials: 'include 를 사용하는 부분이 있다면 이는 클라이언트 환경에서만 적용이 되는 것이므로 headers: { Cookie: cookies().toString() } 를 사용해야 한다라고 저는 이해를 했었기 때문에 getSinglePost 대신 getSinglePostServer 로 분리를 하신거라고 생각했습니다.   근데 기존의 getSinglePost 는 애초에 인증 여부가 필요한 부분이 아니어서 credentials: 'include 는 없었는데 왜 강의에서getSinglePostServer로 따로 분리하시고 headers: { Cookie: cookies().toString() } 를 추가로 적용하셨는지 궁금합니다!

서버 컴포넌트가 프론트 서버에서 미리 렌더링되는 것으로 알고 있었습니다. 이것이 맞을까요??클라이언트 컴포넌트랑 서버 컴포넌트의 렌더링 방식을 찾아봤음에도 여전히 헷갈리는데 시간적 여유가 되신다면 쉽게 알려주실 수 있을까요??클라이언트 컴포넌트 사이에 서버 컴포넌트를 넣으면 렌더링 동작이 어떻게 수행되는지 궁금합니다.강좌에서는 PostArticle이라는 클라이언트 컴포넌트의 자식으로 서버컴포넌트를 넣는데, 공식문서에서는 클라이언트 컴포넌트가 DOM Tree의 끝에 오도록 하는 것을 권장하는 것으로 알고 있었는데 제가 잘못 알고 있던 것이었을까요??

안녕하세요~ 양질의 강의 잘 수강중입니다.https://github.com/mswjs/msw/issues/1801 종종 발생하는 이슈 같은데 (제로초님 코멘트도 있네요!) 저도 제로초님 코드 그대로 따라해보았지만 해당 이슈가 계속 발생하네요ㅠㅠ어떤 문제 때문인지 감이 잘 잡히지 않는데 MSW를 다운그레이드 하는 방법 밖에 없을까요? 조언 부탁드립니다ㅠ

백엔드소스 받아 로컬에 서버 가동시켰고, 레디스 서버도 켜두었고강사님이 올려주신 클라이언트 ch4소스에서 실행시켜, 회원가입 도중 에러가 발생합니다. postresql 디비에는 정상적으로 회원정보가 등록되긴 하였습니다만, 프론트에서 아래와 같은 에러가 있는데요원인이 무엇일까요? Error: CredentialsSignin at signIn (webpack-internal:///(action-browser)/./node_modules/next-auth/lib/actions.js:62:22) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async $$ACTION_0 (webpack-internal:///(action-browser)/./src/app/(beforeLogin)/_lib/signup.ts:53:9) at async /Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:38:489 at async tX (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:37:5313) at async rl (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:38:23339) at async doRender (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/base-server.js:1406:30) at async cacheEntry.responseCache.get.routeKind (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/base-server.js:1567:28) at async DevServer.renderToResponseWithComponentsImpl (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/base-server.js:1475:28) at async DevServer.renderPageComponent (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/base-server.js:1852:24) at async DevServer.renderToResponseImpl (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/base-server.js:1890:32) at async DevServer.pipeImpl (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/base-server.js:902:25) at async NextNodeServer.handleCatchallRenderRequest (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/next-server.js:266:17) at async DevServer.handleRequestImpl (/Users/yhj/Desktop/yhj_projects/next-app-router-z-master/ch4/node_modules/next/dist/server/base-server.js:798:17)

[제로초 강좌 질문 필독 사항입니다]질문에는 여러분에게 도움이 되는 질문과 도움이 되지 않는 질문이 있습니다.도움이 되는 질문을 하는 방법을 알려드립니다.https://www.youtube.com/watch?v=PUKOWrOuC0c0. 숫자 0부터 시작한 이유는 1보다 더 중요한 것이기 때문입니다. 에러가 났을 때 해결을 하는 게 중요한 게 아닙니다. 왜 여러분은 해결을 못 하고 저는 해결을 하는지, 어디서 힌트를 얻은 것이고 어떻게 해결한 건지 그걸 알아가셔야 합니다. 그렇지 못한 질문은 무의미한 질문입니다.1. 에러 메시지를 올리기 전에 반드시 스스로 번역을 해야 합니다. 번역기 요즘 잘 되어 있습니다. 에러 메시지가 에러 해결 단서의 90%를 차지합니다. 한글로 번역만 해도 대부분 풀립니다. 그냥 에러메시지를 올리고(심지어 안 올리는 분도 있습니다. 저는 독심술사가 아닙니다) 해결해달라고 하시면 아무런 도움이 안 됩니다.2. 에러 메시지를 잘라서 올리지 않아야 합니다. 입문자일수록 에러메시지에서 어떤 부분이 가장 중요한 부분인지 모르실 겁니다. 그러니 통째로 올리셔야 합니다.3. 코드도 같이 올려주세요. 다만 코드 전체를 다 올리거나, 깃헙 주소만 띡 던지지는 마세요. 여러분이 "가장" 의심스럽다고 생각하는 코드를 올려주세요.4. 이 강좌를 바탕으로 여러분이 응용을 해보다가 막히는 부분, 여러 개의 선택지 중에서 조언이 필요한 부분, 제 경험이 궁금한 부분에 대한 질문은 대환영입니다. 다만 여러분의 회사 일은 질문하지 마세요.5. 강좌 하나 끝날 때마다 남의 질문들을 읽어보세요. 여러분이 곧 만나게 될 에러들입니다.6. 위에 적은 내용을 명심하지 않으시면 백날 강좌를 봐도(제 강좌가 아니더라도) 실력이 늘지 않고 그냥 코딩쇼 관람 및 한컴타자연습을 한 셈이 될 겁니다.  안녕하세요질문은 인터셉팅라우트의 (.)i폴더 입니다 @modal이 주소에 관계없기때문에(beforeLogin)의 i/flow/login를 대체할 수 있다고 하셨는데요 (beforeLogin)도 주소와 관계가 없다고 하셨어서 (.)i가 무엇을 기준으로 대체하는 것인지 헷갈립니다. 또한 @modal의 경우에는 @modal/i/flow/login과 같이 연결되는 주소가 있어보여서 (.), (..)등의 인터셉팅라우트의 키워드가 무엇을 기준으로 하는지 명확하게 이해가 안됩니다

react-query의 쓰임새가 잘 이해가 안가서 질문드립니다.1. 컴포넌트가 server component 일때는 react-query에 prefetchQuery를 사용하여 미리 서버에서 데이터를 가져오고 dehydrate를 통하여 클라이언트에 전송할수있는 형태로 만들어주고,HydrationBoundary 로 감싸여진 클라이언트 컴포넌트는 서버에서 미리 가져온 데이터를 클라이언트의 쿼리 캐시에 적용하여, getQueryData를 사용하여 네트워크 요청 없이 데이터를 가져올수있고,useQuery 같은 경우에는 미리 가져온 데이터 외에 클라이언트에서 데이터를 가져올 때 사용하는 걸로 이해했습니다. 맞을까요??2. queryKey 같은 경우에는 queryFn에 있는 함수에 queryKey를 넘기는 경우가 있고 안넘기는 경우가 있던데 강의에서 props에 따라 키가 바뀌는 경우에만 넘기게 된다고 이해했습니다.그러면 server component에서 모든걸 prefetchQuery 해서 getQueryData 로 가져다 쓰지 않는 이유가 useQuery를 이용해서 key 값을 다이나믹하게 바뀌는 요청들을 컨트롤 하기 위해서라고 생각이 들었습니다.하지만 아래와 같이 queryKey를 넘기지 않는 경우에도 useQuery를 사용하는데 prefetchQuery를 해놓고 getQueryData 를 사용할지, prefetchQuery 를 사용하지않고 useQuery를 사용할지 에 대해서 나누는 기준이 있을까요?const { data } = useQuery<Hashtag[]>({ queryKey: ["trends"], queryFn: getTrends, staleTime: 60 * 1000, gcTime: 300 * 1000, enabled: !!session?.user, });