안녕하세요 준형님, 이정환입니다. # 질문 1 TypeScript 6.0부터 baseUrl 옵션이 지원 중단(deprecated) 예정으로 바뀌면서 나타나는 경고입니다. 가장 깔끔한 해결 방법은 "baseUrl": "." 줄을 그냥 지우는 것입니다. paths 옵션은 baseUrl 없이도 tsconfig 파일이 있는 위치를 기준으로 경로를 해석하기 때문에, 아래처럼 paths만 남겨 두셔도 경로 별칭은 똑같이 동작합니다. "paths": { "@/*": ["./src/*"] } 이때 경로 앞의 ./ 는 꼭 붙여 주세요. 만약 baseUrl을 지운 뒤 Shadcn/ui CLI(npx shadcn init 등)가 import alias를 찾지 못한다는 오류를 낸다면, 그때는 baseUrl을 그대로 두고 compilerOptions에 "ignoreDeprecations": "6.0" 을 함께 추가해 경고만 숨기셔도 괜찮습니다. 지금 버전에서는 baseUrl이 정상적으로 동작하기 때문에 강의를 진행하시는 데에는 문제가 없습니다. # 질문 2 "작업 영역 버전 사용" 항목은 VS Code에서 연 폴더의 node_modules 안에 typescript가 설치되어 있을 때만 나타납니다. 그래서 아래 두 가지를 확인해 보시면 좋겠습니다. 1. VS Code에서 프로젝트 폴더 자체(package.json이 있는 폴더)를 열었는지. 상위 폴더를 열었다면 항목이 뜨지 않습니다. 2. 프로젝트 폴더에서 npm install을 실행해 node_modules가 생성되어 있는지. 다만 질문 1처럼 baseUrl을 지우셨다면, 지금처럼 "VS Code의 버전 사용(6.0.3)"을 선택하셔도 그대로 진행하셔도 괜찮습니다. tsconfig.node.json에 새로 뜬 빨간 줄은 어떤 옵션에서 어떤 메시지가 뜨는지에 따라 해결 방법이 달라집니다. 빨간 줄에 마우스를 올렸을 때 나오는 오류 메시지를 캡처해서 남겨 주시면 확인해 드리겠습니다!
안녕하세요 박준형님 이정환입니다 아이고 연휴가 길어져 회신이 늦었습니다 🙇♂️ 너무 오래 기다리실듯 하여 일요일 저녁 늦게라도 답변 달아드립니다. 결론부터 말씀드리면 정답은 정해 있지 않으며 박준형님께서 더 먼저 배워보고 싶으신 쪽을 고르시는게 좋습니다. 한입 Next.js와 한입 실전프로젝트 - SNS 강의는 서로 커리큘럼의 선후 관계가 존재하지 않습니다. 병행 진행이 가능한 주소라고 이해하시면 되겠습니다 😀 따라서 React + TypeScript 기반의 실전 프로젝트를 먼저 경험해보고 싶으시다면!? 실전 SNS 프로젝트 강의를 먼저 수강하시길 추천드리고 Next.js에 대해 탄탄히 기초를 다지고 싶으시다면!? 한입 Next.js 강의를 먼저 수강하시길 추천드립니다.
안녕하세요 김태훈님 이정환입니다. 금일 살펴보니 아래 그림처럼 프로젝트 생성 과정에서 OxLint를 사용할지, ESLint를 사용할지 묻는 항목이 추가 되었더라구요! 아마 이 과정에서 OxLint를 선택해 강의와 다른 점이 발생하게 된 것 같습니다. 미리 파악하지 못한 점 사과드립니다 🙇♂️ OxLint 대신에 ESLint를 사용해 강의를 수강하시는 것을 추천드립니다. 강의에도 자동 메세지 기능을 통해 ESLint를 선택하시도록 안내를 추가 해 두겠습니다.
안녕하세요 나마스테님 이정환입니다 우선 말씀하신대로 onSettled 에서 invalidateQueries를 호출하므로 데이터의 용량이 커지면 부하가 발생하는 것은 맞습니다. 그러나 이는 낙관적 업데이트에서 필수적인 사항입니다. 낙관적 업데이트는 서버의 응답을 기다리지 않고 "아마 이렇게 수정되었을 것이다" 혹은 "요청이 무조건 성공했을 것이다" 라고 예상해 캐시 데이터를 미리 바꿔놓습니다. 그러나 캐시 데이터가 실제 서버의 데이터와 100% 일치할 것이라고 보장할수는 없기에 onSettled 에서 실제 서버의 데이터로 교체하기 위해 캐시를 무효화 시켜주고 있는 것 입니다. 이 방식은 Tanstack Query의 공식 문서 예제에도 소개되어 있으며 실무에서도 실제로 자주 사용되는 패턴입니다. 다만 정말 데이터가 커서 부담이 된다면 실무에서는 다음과 같이 해결하기도 합니다. 프론트엔드에서 요청 발생시 일단 onMutate로 낙관적 업데이트 백엔드가 API Response로 결과로 생성된 데이터를 함께 반환 프론트엔드 측에서는 성공 실패 여부에 따라 다음과 같이 동작 onSuccess시 백엔드가 반환한 데이터로 캐시를 맞춤 (setQueryData) onError시 기존의 캐시 데이터로 원복 (요청 이전으로) 위와 같이 설정하면 리스트 전체를 다시 불러오지 않고도 서버의 데이터와 캐시 데이터를 일치시킬 수 있습니다. 다만 구현의 복잡함이 뒤따르고 또 다른 클라이언트의 요청으로 인한 변경 사항은 반영되지 않기 때문에 상황에 따라 적절히 선택해야 할 것 같습니다.
안녕하세요 Shin Kaku님 이정환입니다. 우선 완강을 축하드리며 제 강의를 선택해주셔서 진심으로 감사드립니다 🙇♂️ 마침 내년 상반기에 출시할 강의로 바이브코딩 앱 개발편을 고려하고 있었습니다! 아마 올해 12월 즈음 현재 준비중인 강의 (Claude Code or Codex로 AI Brain 만들기) 이후에 곧바로 제작에 착수할 것 같습니다. 조금만 기다려주시면 감사하겠습니다! 열심히 만들어볼게요 🫡
안녕하세요 ereum999님 이정환입니다. Home에서 받아와야 하는 이유는, 월별로 데이터를 필터링 해 DiaryList 컴포넌트에게 Props로 전달하기 위함입니다. DiaryList 컴포넌트에는 아래와 같은 getMonthlyData 함수가 없기에 상위 컴포넌트인 Home 컴포넌트에서 받아와 필터링을 거친 후 Props로 전달해준다고 이해하시면 됩니다.
안녕하세요 @V님 이정환입니다. 앗 그러네요! TodoList 컴포넌트가 분리된 상황이 아니기에 TodoStateContext가 하위 컴포넌트에서 참조되는 상황은 아닙니다. 그러나 DispatchContext를 별도로 분리하고 향후 TodoList 컴포넌트가 분리될 경우까지 고려해 설계된 구조라고 이해해주시면 감사하겠습니다 😃
안녕하세요 멍멍님 이정환입니다. 우선 말씀하신대로 아래의 타입에서 결과 타입이 never로 향하는 분기는 일어나지 않습니다. 따라서 any로 설정해도 무관합니다. 절대 발생할 수 없는 분기이기에 never 타입을 설정하는게 저도 의미상 올바르다고 생각하는데 내부적인 구현은 any로 되어 있더라구요 ... 정확한 원인은 저도 잘 모르지만 아마 아무 타입이나 넣어둬도 괜찮으니 any를 넣어둔게 아닐까 추측됩니다. type ReturnType any> = T extends (...args: any) => infer R ? R : never;
