ssr질문

안녕하세요 이정환입니다.페이지 라우터 버전의 Next.js 앱의 모든 컴포넌트들은 사전 렌더링 과정 중 최초 1회 실행되고, 이후에 브라우저측에서 실행되어 하이드레이션 될 때 한번 더 실행됩니다. 그런데 이때 사전 렌더링 과정 중에는 코드가 Next.js 서버측에서 동작하므로 window 객체가 존재하지 않습니다. 따라서 질문주신 코드의 조건문은 거짓이 됩니다. 그러나 이후의 하이드레이션 과정 중에 실행될 때에는 코드가 브라우저측에서 동작하므로 window 객체가 존재하여 질문주신 코드가 정상적으로 실행됩니다.

하이라이트 변경이 없는데요?

안녕하세요 민경언님 이정환입니다.다음은 메모를 적용하기 전인 10.3 챕터 강의의 2분 4초경에 확인하는 리렌더링 하이라이트입니다.(사진)자세히 보시면 헤더 컴포넌트의 영역에 하이라이트가 들어오고 있는걸 보실 수 있습니다.헷갈리신다면 별도로 빨간펜으로 칠해 다시 보여드릴게요(사진)이렇게 "오늘은" 이라는 텍스트 부터 "Sun Feb 04 2024" 텍스트 아래 까지 하나의 박스 형태로, Header 컴포넌트가 하이라이트 되고 있는걸 확인하실 수 있습니다. 그리고 다음은 React.memo 적용 후 Header 컴포넌트가 리렌더링 되지 않는다는 것을 확인하고 있는 화면입니다. 강의중 5분 26초 경을 보시면 됩니다.(사진)보시면 위 화면에서는 Sun Feb 04 2024 글자 아래에 경계선이 사라져있습니다. 이를 통해 Header 컴포넌트에는 하이라이팅이 발생하지 않는걸 볼 수 있습니다.이때 Context.Provider 컴포넌트의 리렌더 하이라이팅을 Header 컴포넌트의 하이라이팅으로 착각하실 수 있는데요, 그렇기에 헷갈리신다면 console.log를 통해 확인하시는게 가장 정확하고 빠른 방법이 될 것 같습니다 😃 감사합니다.

Full route cache 질문있습니다.

안녕하세요 Kurt님 이정환입니다.리퀘스트 메모이제이션은 페이지를 생성하는 동안에만 유효하기 때문입니다.이 내용은 우리 강의의 4.3) 리퀘스트 메모이제이션 챕터의 3분 40초에 아래 슬라이드로 설명드렸었는데요(사진)리퀘스트 메모이제이션의 목적은 하나의 페이지를 렌더링 하는 동안에 (즉 한번의 요청을 처리하는 동안에) 중복된 API 요청을 방지하기 위해 존재합니다. 따라서 브라우저의 접속 요청에 페이지 생성을 완료하게 되면 리퀘스트 메모이제이션에 저장된 모든 캐시는 다 소멸됩니다. 그리고 이것이 바로 데이터 캐시와 리퀘스트 메모이제이션의 차이점입니다.

줄바꿈 단축기 질문 _4분 20초

안녕하세요 이정환입니다.코드 저장시 코드의 포맷을 자동으로 정리해주는 Prettier 라는 도구 입니다.1.2) VSCode 설치하기 챕터에서 설치 과정을 다루고 있으니 참고 하시면 될 것 같습니다.

감정다이어리 edit 컴포넌트 만들때

안녕하세요 삘소굿님 이정환입니다.해당 강의 "12.8 챕터"의 7분 10초 확인해보시면 질문하신 코드와 동일한 코드를 사용하는걸 보실 수 있습니다. (사진) 추가적으로 질문 있으시면 답글 달아주세요

수업 노트 링크 오류 제보

안녕하세요 강프로그래머님 이정환입니다.아이고.. 제보 감사합니다 바로 수정해 두었습니다!

section 02 타입스크립트 컴파일러 옵션 설정하기 파트에서 24분쯤 진행되는 ts-node 옵션관련 질문

안녕하세요 이정환입니다.먼저 이 부분은 타입스크립트 관련된 내용이라기 보다는 ts-node 라이브러리의 동작에 관련된 원리이므로 저도 현재로써는 정확한 원인을 알고 있지는 않습니다 🥲 (ts-node가 공식 라이브러리도 아니다보니 중요하지 않다고 생각하고 있습니다)더불어 tsconfig.json을 비워두고 타입스크립트를 사용하는 것은 사실상 불가능에 가깝고, 또 ts-node는 Node 20v+ 이상의 환경에서 정상적으로 동작하지 않고 있으며 이를 알고 있음에도 빠른 이슈 해결이 되지 않는 상황이라 이를 심도있게 고려하고 있지는 않습니다.이에 제가 지금으로써는 알려드릴 수 있는 이야기가 딱히 없을 것 같아요 ㅠㅠ 시간될 때 조사해 보고 알게되면 추가로 답글 남겨드리겠습니다. 가급적 tsx를 사용하시는걸 권장드립니다.

ISR 구현에 궁금한 점이 있습니다.

안녕하세요 이정환입니다. 순서대로 답변드리겠습니다. 1) ISR우선 ISR은 SSR의 형태가 아닌 SSG의 업그레이드 형태입니다.SSR은 Server Side Rendering의 약자로, 런타임에 매 요청마다 실시간으로 페이지를 생성하는 방식이고, SSG는 Static Site Generation의 약자로, 빌드 타임에 미리 정적으로 페이지를 생성해두는 방식입니다.일정시간을 두고 페이지를 재 생성한다는 말은 빌드를 다시 한다는 이야기는 아닙니다. Next.js 서버가 자체적으로 브라우저로부터 요청이 발생한 것 처럼, 페이지 컴포넌트를 실행하여 정적인 HTML 페이지를 생성해 서버측에 저장해둔다는 이야기 입니다. 더 쉽게 이야기하자면 정적으로 빌드 타임에 생성된 페이지를 백그라운드에서 다시 생성해 캐시를 갱신한다고 이해하시면 될 것 같습니다.빌드를 하지 않아도 서버측 백그라운드에서 페이지 생성은 얼마든지 가능합니다 😃 이는 Next.js가 제공하는 기능입니다.2) 동적 경로를 갖는 페이지 + SSG 방식으로 렌더링하기네 맞습니다. 캐싱이 되어 있지 않은 페이지는 실시간으로 생성해 응답 + 캐싱에 저장하고, 캐싱이 되어 있는 페이지는 캐싱된 페이지를 응답하는 방식으로 동작합니다. 추가적으로 궁금하시거나 사소하게라도 헷갈리시는 부분 있으면 편하게 답글 or 추가 질문 부탁드립니다! 감사합니다 codeflow님도 감기 조심하시구 새해 복 많이 받으세요 🙇‍♂

tsc와 tsx가 타입검사를 안하는거 같습니다.

안녕하세요 이정환입니다.우선 TypeScript 컴파일러의 동작은 tsconfig.json에 설정하는 옵션에 따라 유동적으로 변경될 수 있습니다. 따라서 기본적으로 아무 옵션도 커스텀 하지 않은 경우 말씀하신 것 처럼 타입 체킹시 오류가 발생하더라도 JS 파일로 컴파일은 완료됩니다. (타입 체킹은 동일하게 이루어집니다)그러나 이렇게 되면 타입스크립트를 사용해 보다 견고한 프로그램을 작성하기 어려워지므로 보통의 Vite, Webpack 등을 사용하는 프로덕션에서는 타입체킹 에러 발생시 컴파일 결과로 JS 파일을 생성하지 않도록 하고 있습니다. 그리고 이를 명시적으로 설정하는 옵션은 noEmitOnError입니다.따라서 다음과 같이 tsconfig.json의 compilerOptions를 설정하신 다음 다시 tsc로 컴파일 해 보시면 타입 에러 발생시 js 파일로 컴파일 되지 않을 것 입니다.{ "compilerOptions": { "noEmitOnError": true } }

타입스크립트 설치에 대해 질문있습니다.

안녕하세요 이정환입니다.우리 강의의 "ts-node가 동작하지 않는다면"에 설명해 두었듯이, 이제 ts-node 대신 tsx를 사용하셔야 합니다. 자세한 정보는 해당 챕터 확인 부탁드립니다.(사진)