문제 발생 : npm run start:dev 시 위와 같은 에러 발생 Error: connect ECONNREFUSED ::1:6379 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1615:16) { errno: -4078, code: 'ECONNREFUSED', syscall: 'connect', address: '::1', port: 6379 } 문제 원인: Redis 연결 실패 → 애플리케이션이 Redis 서버(포트 6379 )에 연결하려 했지만 거부됨. ECONNREFUSED 오류는 Redis가 실행되지 않거나, 접근할 수 없는 상태 일 때 발생. 문제 해결 : Redis 기본 설정은 IPv6 ( ::1 )을 사용함. IPv4( 127.0.0.1 )로 강제 변경해 해결 localhost 가 아닌 127.0.0.1 로 변경 // .env 기존 코드 REDIS_URL=redis://localhost:6379 // .env 변경 코드 REDIS_URL=redis://127.0.0.1:6379 위 에러 만나고 애쓴 부분 공유합니다. 혹시 잘못된 해결 방법이라면 알려주시면 감사하겠습니다!
해당 강좌 default.tsx에서 기본 페이지로 사용시킬때 default.tsx를 처리해두고 빈페이지를 구성하는 형태를 사용하는 예제를 따라서 진행해보았는데요. 여기서 궁금한점이 page.tsx를 @modal에 하나더 유지시키고 return null 처리를 하는 컴포넌트를 두어도 똑같이 동작은 되는데, default.tsx 를 좀 더 권장하는 이유가 있을까요?
아래가 제가 이해한 내용인데 맞을까요? 요청 메모화 ssr 요청 사이클 내 에서만 페치 결과를 캐싱하여 중복 요청 방지 (한 서버 요청 사이클 끝나면 초기화) 예를들어 Home컴포넌트와 자식 컴포넌트인 Header 컴포넌트에서 렌더링 시 에 동일한 요청을 날렸다면 Home컴포넌트의 요청이 캐싱되고 Header 컴포넌트의 요청은 캐싱된 값 사용 데이터 캐시 한 ssr 요청 사이클 내 뿐만 아니라 서버에 전역적으로 유지되는 캐시 요청 메모화와 다르게 서버 요청 끝나도 초기화되지 않고 지속됨 즉, 여러 클라이언트 요청 간에도 유지됨 A가 먼저 페이지 요청 → 백엔드에 요청 후 넥스트 서버에 데이터 캐싱 B가 같은 페이지 요청 → 백엔드 요청 없이 넥스트 서버 캐시에서 데이터 반환 결론 즉, 요청 메모화는 렌더링 최적화 , 데이터 캐시는 네트워크 요청 절약 을 위한 것
Next.js에서 서버 컴포넌트는 서버에서 실행되기 때문에, useEffect 없이 컴포넌트 내부에서 직접 fetch 요청을 보낼 수 있는 것으로 알고 있습니다. 또한, 서버 액션은 백엔드 없이 Next.js 풀스택 환경에서 DB에 직접 접근할 때 주로 사용하는 것으로 이해하고 있습니다. 그렇다면, 별도로 백엔드가 존재하는 경우에도 서버 액션을 사용할 필요가 있나요? 그리고 실제로 현업에서도 백엔드가 따로 있을 경우에 서버액션을 사용하나요? 감사합니다!
next는 자동적으로 캐시 저장기능이 있고 next에서도 DB 데이터가 필요한 페이지에서 직접 불러와서 사용하는 것을 권장한다 라고 말씀해주셨는데요 그러면 next는 보통 zustand, recoli, redux와 같은 상태관리 라이브러리를 사용하지 않는 것을 추천하시나요? 아니면 사용하는 것을 추천하시나요??
안녕하세요! 덕분에 nextjs에 대해 깊에 알아가고 있습니다. 제목처럼 page 컴포넌트에 'use client'를 명시하고 빌드 해도 해당 페이지에 대한 rsc_payload가 생성되어서 .next 빌드 파일을 살펴 보았습니다. 페이지를 클라이언트 컴포넌트로 작성하던 서버 컴포넌트로 작성하던 .next 빌드 파일 server, static/chunk/app 폴더에 모두 page.js 파일이 생성되는 것을 확인했습니다. 1. server 폴더에 있는 page.js는 해당 페이지에 필요한 번들 파일에 대한 내용인 거고, static 폴더에 있는 page.js는 해당 페이지에 그려질 내용에 대한 파일인 건가요?? 2. 그래서 page컴포넌트를 클라이언트 컴포넌트로 만들어도 페이지에서 사용할 번들 파일의 주소를 알아야 하기 때문에 rsc_payload를 만들어서 내려주는 건가요??
레이아웃은 네비게이션을 해도 상태를 유지하고 렌더링을 하지 않는다라고 이해했습니다. 그런데, 오른쪽 레이아웃을 만들면서 패러렐 라우트라던지 template를 쓰지 않고 (비록 컴포넌트를 분리하긴 했으나) 서버에서 데이터를 뿌려주는 미래를 상상하고 쭉 코드를 짜고 계시는 모습을 보면서, 레이아웃이 서버 데이터는 변경사항을 화면에 반영해주는 것처럼 이해가 되었습니다. 뒷부분은 수강하지 않았습니다. 제가 잘못 이해 중인가요?
안녕하세요 ! 강의를 듣기전부터 궁금했던 내용인데 강의를 듣고나서도 답을 찾지 못해서 질문을 남깁니다..! 개발자도구 > Network 탭 > 문서 > 응답 이나 소스보기 에 서버사이드에서 불러온 데이터가 HTML 로 만들어져있으면 SEO 에 영향을 주는 데이터라고 알고 있어요 제가 혼자 테스트해보려고 만든 스트리밍에서는 <script /> 내부에만 서버 사이드에서 패치한 데이터가 들어가있고 HTML 로 만들어지지는 않았더라고요 ( 아마 <script /> 에 있는 정보가 RSC Payload 겠죠..? ) 그래서 이게 SEO 에 영향이 가는 데이터일지 궁금해서 여기저기 찾다가 발견한 Next Playground 에서는 HTML 로도 만들어지고 <script /> 에도 들어가있더라고요 최종적으로 궁금한것은 <script /> 에만 들어있는 스트리밍된 데이터도 SEO 에 영향을 주는지 가 궁금해요 그리고 영향을 주든 안주든 이런 정보는 어디서 찾아봐야하는지 어떻게 검증하는지 알고 싶습니다..! ( 참고로 Playground 에서 패치하는 첫번째 리스트의 이름인 Fusce commodo porta 로 확인해봤습니다! )
안녕하세요 덕분에 next.js를 깊게 공부할 수 있었습니다. next.js는 기존 리액트와 다르게 jsbundle(청크) 파일을 나누어 받아 옵니다. 강의에서 본 것처럼 청크 파일들이 각각의 유니크한 해쉬 값을 가지는 것도 확인했습니다. 시나리오 next 프로젝트를 빌드 배포 된 웹페이지를 오픈 next 프로젝트를 다시 빌드 기존의 웹페이지를 새로고침 하지 않고, 페이지 이동 기존 리액트 프로젝트에서는 하나의 청크 파일을 처음 한 번에 받아서 새로고침 전까지 1번의 이전 빌드된 웹페이지로 동작이 되는 것으로 알겠는데요. next프로젝트에서는 jsbundle과 rsc_payload를 필요한 시점에 받으니까 새로 빌드한 파일엔 기존 청크해시 값과 달라서 문제가 생기지 않을까? 라는 생각이 들었습니다. 그런데 테스트 해보니 별다른 문제가 생기지 않는 것 같더라구요.. jsbundle과 rsc_payload의 유니크한(해쉬) 파일 이름이 도중에 변경 되더라도 next 서버측에서 찾을 수 있게 조치가 되어 있는 걸까요?
현재 강의와 관련없는거 알지만 혹시나해서 문의남깁니다. 현재 강의 구매한 분들 대상으로 [코드캠프] 부트캠프에서 만든 '완벽한' 프론트엔드 코스 강의 90% 할인해서 구매할 수 있었던 것으로 기억하는데, 이미 기간이 끝난거 알지만 지금이라도 할인된 가격으로 구매할 수 있을까 해서 문의남깁니다.
강의와 같이 구현한다면 page.tsx 에서 데이터 fetch PostRecommends.tsx 에서 는 다시 데이터를 fetch 하지 않고 HydrationBoundary를 통해 넘어온 데이터를 사용 이렇게 page.tsx 에서만 데이터가 fetch 되어야 맞는거지요 ? 제가 구현한 소스코드에서는 getPostRecommends 쪽에 로그를 찍어서 확인해보니 page.tsx 에서도 한번 호출하고 PostRecommends.tsx 에서도 한번 호출해서 총 2번 로그가 찍히더라구요. 이론대로라면 page.tsx 에서 1번 호출했을 때만 로그가 찍혀야 하는 것이 맞는거죠? 아 강의는 " 클라이언트 react-query" 입니다.