안녕하세요 제로초님 저는 react app 개발만 조금 해봤는데, next 강의에서 server action을 처음 접하면서 헷갈려서 질문 드립니다. 예를 들어서 게시판 목록을 불러올 때 server fetch를 통해 화면에 출력하고 있고, 무한스크롤이나 add, edit, delete 동작 등을 server action으로 할 수 있다는 것을 알았는데요. 그렇다면 next app을 개발할 때는 client fetch는 전혀 필요가 없는 건가요? 아니면 어떤 필요에 따라 client fetch와 server fetch를 혼용해서 사용해야 하는 건지.. 궁금합니다. 감사합니다!
안녕하세요 제로초님. Parallel Routes에 대하여 질문있습니다 (공식문서 폴더구조) 우선 공식문서대로 위와같은 폴더구조로 한 후 export default function Layout({ children, team, analytics, }: { children: React.ReactNode analytics: React.ReactNode team: React.ReactNode }) { return ( <> {children} {team} {analytics} </> ) } Layout에 team과 analytics를 props로 주게되면 team과 analytics에 있는 page.js 가 잘 렌더링 되는 것을 확인하였습니다. 그래서 이것을 강의에 응용해보려고 했습니다. (강의 폴더구조 및 응용) src/app/(afterLogin)/@team (afterLogin)폴더에 @team 폴더를 만들고 그 안에 default.tsx 랑 page.tsx 파일을 만들었습니다. default.tsx 파일이 없으면 404 not found 가 뜹니다. 그 후 AfterLoginLayout에 team을 props로 두어 렌더링하였습니다. 결과는 default.tsx가 렌더링 되었습니다. src/app/(afterLogin)/layout.tsx type Props = { children: ReactNode; team: ReactNode}; export default async function AfterLoginLayout({ children, team }: Props) { return ( <> {children} {team} </> ); } 공식문서에서 default.tsx 는 "초기 로드 또는 전체 페이지 다시 로드 중에 일치하지 않는 슬롯에 대한 폴백으로 렌더링할 default.js 파일을 정의할 수 있습니다." 즉 파일을 찾지 못하여 default.tsx를 렌더링 한다는 말이라고 이해했습니다. 즉 궁금한 것은 공식문서 폴더구조에서는 @team폴더의 page.tsx를 렌더링하는 반면 강의 폴더구조에서는 page.tsx를 렌더링하지 않고 default.tsx를 렌더링하는지 궁금합니다. 해당 강의에서 설명해주신 것 같아 여러번 보았지만 저의 이해력이 안좋아 질문드립니다. ㅜㅜ 항상 좋은강의 감사드립니다!
강사님의 컴포넌트를 나눌 때의 기준이 궁금한데요. 지금까지 제가 이해한 내용으로는 반복되는 부분은 컴포넌트 화 시켜서 공통컴포넌트 _component폴더에 두시는것 같습니다. 제가 궁금한 것은 (afterLogin)/home/page.tsx 내부 구조가 컴포넌트만 있는데 (사진첨부) (afterLogin)/layout.tsx 파일의 내부구조는 컴포넌트화 되어있는 부분이 섞여있습니다 page는 모두 컴포넌트화 시키셨는데 layout은 왜 모두 컴포넌트화를 시키지 않으셨을까요? 따로 컴포넌트화 하시는 기준이 있을까요?
Next.js는 라이브러리에서 보내는 요청까지 캐싱해버리는데, export const dynamic = 'force-dynamic' 해당 문구를 page.tsx에 넣어주면 해당 페이지에서 보내는 모든 요청을 캐싱하지 않음 . => export const dynamic = 'force-dynamic'를 적용한 page.tsx 는 써드파티 라이브러리의 백엔드 요청 캐싱을 무시한다. 또한, 모든 요청을 캐싱하지 않기 때문에 react query나 fetch 함수의 요청도 모두 캐싱을 하지 않는다. 라고 이해했는데 잘 이해한 것인지 모르겠어서 질문 올리게 되었습니다.
안녕하세요! 개인 프로젝트에서 백엔드 먼저 개발 후 프론트를 Next로 개발하면서 강의를 통해 next-auth를 접했는데요. 저는프론트에서 로그인을 하면 해당 로그인 request가 서버로 전달되고, 서버에서 jwt access, refresh token을 발급해프론트에 전달하고 저장하는 기존의 서버 로그인 방식으로 설계를 하였습니다. 또한 서버의 protected request에 대해 위에서 발급한 access token을 활용하여 유효한지 검증 후 진행하도록 하고자 하는데요. next-auth부분을 보며 현재의 공식 문서와도 조금 다르고 제가 원하는 방식과 통합하여 구현이 가능한지 잘 이해가 안가더라구요ㅠ 혹시 이러한 방식으로도 서버에서 얻은 jwt토큰을 next-auth에 삽입이 가능할까요? 대략적인 흐름은 어떻게 진행될까요?
안녕하세요. 실무에서 인터셉팅 라우팅 활용 빈도가 잦을까요? 클론코딩이라 x.com 에서 사용한 방식 그대로 만들기 위한 학습인지 아니면 실무에서도 사용빈도가 높은지 궁금합니다 강의는 들어서 인터셉팅 라우팅을 이해하긴 했지만 실무에서는 로그인, 회원가입 팝업 띄울때 인터셉팅 라우팅을 사용하지 않을것같은 생각이 들어서 질문드립니당 감사합니다
안녕하세요. 강사님 😎 유저 프로필 페이지의 팔로우 버튼을 구현 중에 있었습니다. 예제를 따라하던 중 아래 캡처 이미지와 같이 API /api/users/{id} 의 응답 데이터에 Followers 객체가 없는걸 확인했습니다.. Followers 정보가 없어 세션과 비교하여 팔로잉 여부를 체크할 수가 없네요. 제가 API나 코드를 잘 못 구현하고 있는걸까요?ㅠㅠ (스웨거 및 query-devtool) 강의 영상에는 존재하고요. 추가질문 공부를 집에서는 데스크탑, 카페에서 노트북으로 하다보니 서버를 각각 피씨에 띄우는게 번거로워 하나의 서버를 바라보게 하려고 했습니다. 그래서 개인 서버에 docker형태로 BE서버를 동작시켜 사용하려고 했습니다. 서버는 정상적으로 구동했으나 API 중 인증(로그인)이 필요한 API는 모두 403으로 응답이 오네요ㅠㅠ 방식. 로컬next( localhost:3000 ) -> 외부.BE 서버(be-server:9090) 호출 nest를 알지 못해 깊게 분석은 못해봤고 소스의 logged-in-guard.ts 에 request를 로그로 찍으니 cookie부분이 가 비어 있습니다. import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common'; import { Observable } from 'rxjs'; @Injectable() export class LoggedInGuard implements CanActivate { canActivate( context: ExecutionContext, ): boolean | Promise<boolean> | Observable<boolean> { const request = context.switchToHttp().getRequest(); console.log(request) return request.user?.id && request.isAuthenticated(); } } 간단하게 해결이 가능하면 조언부탁드리며 아니면 무시해주셔도 됩니다. 🙏
안녕하세요 제로초님! 강의 잘 듣고 있습니다. 화면이 mount 되었을 때는 최상단에 존재하는 page.tsx에 의해 localhost:3000 URL가 나오고 있는 상황입니다. 그런데 처음 mount 되었을 때 localhost:3000/login 형태의 URL을 가지려고 한다면 어떤 방법으로 해야할지 궁금합니다! 제가 생각한 방법은 아래와 같은데 좀 더 좋은 방법이 있을까요? 1. 최상단에 존재하는 page.tsx에서 useEffect 내부에 router.push('/login') 을 한다. next 에서 제공하는 redirect 기능을 사용한다.
지금 제로초님은 벡엔드와 프론트서버를 구분해두셨고 백엔드서버는 ec2에 올리지않아서 백엔드와 관련된 것들은 작동하지 않는 상태인데, 만약에 fetch할때 백엔드서버주소가 아닌 프론트쪽 경로로 해서 하면 본 강좌에서 한것과 같이 ec2로 배포를 해도 작동을 할까요? 아니면 이경우 배포방법이 달라지나요?
안녕하세요! 강의와 직접적으로 관련된 질문은 아니지만 도저히 해결책을 도저히 찾기가 어려워서 질문 글 올립니다.. 하나의 Next.js 프로젝트에서 백엔드 api를 구성할 때, node.js와 파이썬 서버리스 함수를 함께 사용할 수 있나요? 백엔드로 파이썬 서버리스 함수를 단독으로 사용하는 것은 가능한 것 같은데, 동일한 프로젝트에서 node.js 서버리스 함수와 함께 사용할 수 있는지가 궁금합니다..
안녕하세요. 첫번째 질문은 onMutate vs onSuccess 인데 사실 낙관적 업데이트를 해주냐 안해주냐에 따라서 기호에 따라 다른 경우는 알겠습니다. 제가 궁금한거는 onSuccess invalidatequeries 를 무지성으로 사용해도 query-key외 따로 전달 되는 params값이 중요하진 않은 것 같아서 쉽게 적용 했었던 기억이 있는 것 같습니다/ 예를 들면 onSuccess를 해주는 mutation에 invalidatequeries로 invalidatequeries(['key', {...}]) 를 굳이 안하고 invalidatequeries(['key']) 요거만 해줘도 새로 캐싱된 API를 새로 조회 하는 것 같더라구요. 근데 onMutate를 쓰려는 경우에 getQueryData 에 query-key 정보와 그에 매칭하는 파라메터를 정확하게 넘겨주지 않으면 undefined 같은데 애초 설계 할때 getQueryData뒤에 보내는 파라메터를 잘 가져 올 수 있게 해야 할지 혹시 다른 방법이 있는지 궁금합니다. query에서 find해서 찾기는 보장이 안되는 것 같구요? 이건 사용자가 셀렉트 박스로 막 선택해서 조회 다시 이전것 조회 요런식으로 하다보니 마지막으로 선택된 파람 정보가 명확하진 않더라구요. 현재는 혹시 모르니 전부 searchParams로 개편은했지만.... 실제 프로젝트에서는 어드민성(?) 서비스를 제공 해서 ux는 딱히...?????? 엄청 중요한 않기도 했고 지식도 부족해서 onMutate 대신에 onSuccess를 썼지만 보통은 좀 어떻게 잘 써야하는지 궁금합니다. 2번째 질문은 이건 진짜 뭘 더 써야하는지 모르겠습니다. 쓰임에 따라 다르게 써야한다면 어떤 경우인지 취향에 차이라면 취향것 쓰면 되는건지 궁금합니다
수업을 다 듣고 저 스스로 코드를 짜던중 갑자기 놓친부분이 있는 것 같아 여쭤봅니다. 혹시 <search/page.tsx> export default function Search({ searchParams }: Props) { 여기서 이 search/page.tsx의 매개변수는 누가 넘겨주는 걸까요?
