안녕하세요. 강의를 구매할 때 저는 '프레임워크 선택: React 19 & Next.js 16'과 BFF 부분이 궁금해서 강의를 구매하게 되었는데요. 다시 보니 해당 부분이 10월 15일 삭제 예정으로 되어 있던데, 오늘 삭제될 예정인가요? 아래 문의 글을 보니 11월까지는 연장할 계획이 있으시다고 되어 있는데, 그렇다면 혹시 언제까지 남겨 두실 예정인가요? 이 부분이 삭제되면 저는 강의를 구매한 의미가 없어지는데, 해당 내용이 다른 강의로 옮겨지는 걸까요?
DOM에서 픽셀까지, 브라우저 렌더링과 CRP 완전 정복 - [DOM 완전 정복 Part 3]
Composition(합성)단계에서는 여러 Layer를 가지고 하나의 화면에 합성시킵니다. 그런데... 그 여러개의 Layer들은 누가 만드는건가요? Layout > Painting > Composition 단계에서 갑자기 여러개의 Layer가 나타나니까 혼란스럽네요. 요약하면... Layer 여러개는 어떤 단계에서 생성되는건지? 혹시, 렌더트리 여러개가 Layer 여러개인건지?
안녕하세요, FE 개발자 준비중인 수강생입니다! 해당 강의 화면에서 Strict Mode에서 두번 실행시 값이 반복 변경되어있다고 작성되어있는데 해당 예시로는 객체 내부 값을 변경해서 2번을 실행해도 같은 값이 나올 것 같은데, Strict Mode에서 감지된다는 적절한 예시가 맞을까요? 제가 잘못 알고 있는 점이 있다면 말씀해주시면 감사하겠습니다:)
안녕하세요. 좋은 강의 감사합니다. 소식에 올려주신 저자 블로그를 보다가 동영상 강의 도 있다는 것을 알게 됐는데요. 혹시 어떤 식으로 구성돼 있는지 알 수 있을까요? 본 강의인 Frontend System Design Essentials 책을 그냥 강의로 옮긴 수준인지, 그 이상의 무엇이 있는지 궁금해요.
React 마스터 클래스: Part 3 - 실무 핵심 라이브러리 정복 (TypeScript, Zustand, React Hook Form, TanStack Query)
안녕하세요. Context API의 대안으로 Zustand를 사용할 때의 장점과 함께, Zustand가 반드시 Context API를 대체하는 것이 아니라 상태의 특성에 따라 전략적으로 선택해야 한다고 설명해주셨습니다. 예를 들어 다크 모드나 다국어 설정처럼 변경 빈도가 낮으면서 여러 컴포넌트에서 공유해야 하는 상태의 경우 Context API도 충분히 적합할 수 있다고 이해했습니다. 제가 이해한 바로는 Context API가 적합한 경우를 크게 다음과 같이 생각해볼 수 있을 것 같습니다. 특정 컴포넌트와 그 하위 컴포넌트에서만 공유해야 하는 상태 Provider의 범위를 해당 컴포넌트 트리로 제한하여 사용하는 경우 애플리케이션 전역에서 공유하지만 변경 빈도가 낮은 상태 다크 모드 다국어 설정 전역 configuration 등 반면, 전역에서 사용하면서 변경이 빈번하거나 여러 상태를 세분화하여 구독해야 하는 경우에는 Zustand와 같은 외부 상태 관리 라이브러리가 더 적합할 수 있다고 이해했습니다. 1. Context API에 대한 제 이해가 맞을까요? Context API와 Zustand를 선택할 때 단순히 Local vs Global만으로 구분하기보다는, 상태의 변경 빈도 해당 상태를 구독하는 컴포넌트의 범위 상태 변경으로 인한 리렌더링의 영향 등을 함께 고려해야 한다고 이해했는데, 이 방향이 맞는지 궁금합니다. 혹시 이 외에도 Context API와 Zustand를 선택할 때 중요하게 봐야 하는 기준이 있을까요? 2. 그렇다면 Auth 상태는 어디에서 관리하는 것이 좋을까요? Auth의 경우에는 실무, 프로젝트 작업을 할 때 상태 관리를 어떻게 해야할지 판단이 어렵고 로직을 짜는데 항상 이게 맞나? 괜찮나? 라는 고민을 가졌습니다. 예를 들어 서버에서 현재 로그인한 사용자 정보를 받아온다고 했을 때 다음과 같은 방법들을 생각해볼 수 있을 것 같습니다. TanStack Query로 auth/user 데이터를 가져오고 Query Cache 자체를 상태로 활용 TanStack Query로 데이터를 가져온 뒤 Context API를 통해 공유 TanStack Query로 데이터를 가져온 뒤 Zustand Store에 저장하여 사용 여기서 궁금한 점은 서버에서 가져온 auth/user 정보가 본질적으로 server state라면 TanStack Query의 cache를 그대로 single source of truth로 사용하는 것이 더 적절한지, 아니면 Context나 Zustand에 별도로 저장하여 client state로 관리하는 것이 적절한 경우도 있는지입니다. 특히 TanStack Query에서 가져온 데이터를 다시 Context나 Zustand에 저장하면 동일한 데이터가 두 곳에 존재하게 되는데, 이런 형태는 가급적 피해야 하는지도 궁금합니다. 3. React / Next.js와 인증 방식에 따라 기준이 어떻게 달라질까요? Auth 상태 관리는 프레임워크와 인증 방식에 따라서도 달라질 것 같습니다. 예를 들어 다음 네 가지 경우를 생각해봤습니다. React + 클라이언트에서 JWT 관리 React + 서버 Session 기반 인증 Next.js + 클라이언트에서 JWT 관리 Next.js + 서버 Session 기반 인증 각각의 경우에 인증의 source of truth를 어디에 두고, Context API / Zustand / TanStack Query 중 어떤 역할을 맡기는 것이 적절한지 궁금합니다. 단순히 “Auth는 Context”, “전역 상태는 Zustand”처럼 정해진 기준보다는, 인증 정보의 source of truth가 어디에 있는지, server state와 client state 중 어디에 해당하는지, 그리고 해당 상태를 어떤 범위에서 소비하고 변경하는지 를 기준으로 판단해야 할 것 같은데, 이 관점이 맞는지도 궁금합니다. 4. Route 접근 제한은 어느 계층에서 처리하는 것이 적절할까요? Auth 상태 관리와 함께 궁금한 부분이 인증 여부에 따른 route 접근 제한입니다. 예를 들어 로그인한 사용자만 /dashboard , /mypage 등에 접근할 수 있도록 제한한다고 했을 때, React와 Next.js에서는 접근 방식이 다를 수 있다고 생각했습니다. React + React Router v7 React SPA에서는 서버가 아닌 클라이언트에서 routing이 이루어지기 때문에 다음과 같은 방법들을 생각해볼 수 있을 것 같습니다. Context/Zustand의 auth 상태를 확인한 뒤 컴포넌트에서 redirect React Router의 loader에서 인증 상태를 확인하고 redirect 서버 API 요청 시에도 별도로 인증/인가 검증 이 경우 UI 레벨에서의 route protection과 실제 보안을 위한 서버의 인증/인가를 어떻게 구분해야 하는지 궁금합니다. 또한 Context나 Zustand의 isAuthenticated 같은 client state를 기준으로 route 접근을 제한하는 것이 적절한지, 아니면 서버의 session/token 검증 결과를 기준으로 접근 여부를 판단하는 것이 더 적절한지도 궁금합니다. Next.js Next.js에서는 React SPA와 달리 서버에서 인증 정보를 확인할 수 있기 때문에, Server Component에서 session/cookie를 확인 Middleware 또는 Proxy를 통한 route 단위의 사전 처리 Client Component에서 Context/Zustand의 auth 상태를 확인하고 redirect 실제 Server Action/API에서도 인증 및 권한 검증 등 여러 계층에서 접근 제한을 처리할 수 있다고 알고 있습니다. 이때 궁금한 점은 어느 계층에서 route 접근을 제한하는 것이 가장 적절한지, 그리고 각각의 역할을 어떻게 구분해야 하는지입니다. 예를 들어, “로그인하지 않은 사용자에게 페이지 자체를 보여주지 않는 것”과 “해당 사용자가 실제 데이터나 API에 접근하지 못하도록 보안을 적용하는 것”은 별개의 문제로 보고 각각 처리해야 하는지 궁금합니다. 결국 route protection 역시 Context API / Zustand 중 무엇을 사용하느냐보다, 인증의 Source of Truth가 어디에 있는지 → 어느 시점에 인증 여부를 확인할 수 있는지 → UI 접근 제어와 실제 서버의 인증/인가를 어느 계층에서 담당할 것인지 를 먼저 결정하는 것이 맞는지도 궁금합니다. 추가적으로 실무 관점에서의 예시도 궁금합니다. 가능하시다면 위 질문들에 대해 개념적인 기준뿐만 아니라, 강사님께서 실제 프로젝트를 설계하신다면 각각 어떤 방식을 선택하실지도 궁금합니다. 뿐만 아니라 실무에서 일반적으로 많이 사용하는 패턴이 있는지, 또는 정해진 표준이 없다면 강사님의 실무 경험에서는 어떤 구조를 주로 선택하셨고, 그렇게 선택하신 이유가 무엇인지도 함께 설명해주시면 정말 도움이 될 것 같습니다. 가능하다면 단순한 개념 설명뿐만 아니라 간단한 프로젝트 구조나 코드 예시도 함께 보고 싶습니다.
안녕하세요! 6번 강의의 24:15 부분 즈음부터 설명하시는 장치 의존성에 대해 궁금한 점이 있어서 질문드리려고 합니다. 강의를 들으면 마치 "장치 의존성을 해결하기 위해 React.js와 같은 CSR 방식이 등장하였다."라고 이해하게 되는데, 그런 의도로 말씀하신게 맞는지 궁금합니다. 만약 그러한 의도로 말씀하신 것이 맞다면, 제가 알고 있는 내용과 많이 다른 것 같아 혼란스러워 질문을 작성하게 되었습니다. 제가 기존에 알고 있던 지식으로는, 다양한 화면의 장치에 대응하기 위해(즉, 장치 의존성을 해결하기 위해) "반응형 웹 디자인"이 등장한 것으로 알고 있는데요. HTML은 어떤 장치에서 받든 해당 파일을 구동하는 장치(구체적으로는 프로그램)에서 사용할 수 있게 결국 파싱이 되니까(Ex. DOM 생성) 장치에 의존하지 않는 것 아닌가요? 화면의 크기마다 달라지는 UI를 제어하기 위한 방법으로는 CSS에서의 반응형 웹 디자인으로 알고 있었는데요.. React.js와 같은 CSR이 등장하게 된 배경은 다양한 화면에 맞게 알맞은 UI를 보여주려고 한다기보다는, 웹 서버로 보내는 요청을 획기적으로 줄여(클라이언트의 브라우저에서 JS를 이용해 직접 index.html에서 필요한 요소(컴포넌트)를 리렌더링하므로) 웹 서버가 SSR 방식으로 설계되었을 때보다 더 적은 부하를 맡게 되고, 클라이언트 입장에서는 부드러운 화면전환을 경험할 수 있게 하기 위함으로 알고 있는데요. CSR 방식 자체가 장치 의존성을 해결할 수 있는 것이라면 그 이유가 무엇인지 궁금합니다!
강의 예제에서 add(2,3) -> 항상 5 (순수) getTime() -> 실행 시점마다 달라짐 (순수 아님) "실행 시점 마다 달라진다 또는 전역 변수를 수정하는 함수는 같은 입력을 넣어도 실행 시점에 따라 결과가 달라지기 때문에 순수하지 않습니다. "라고 하셨고, 이와 마찬가지로 "순수 컴포넌트는 동일한 props와 state가 주어졌을 때 항상 동일한 UI를 반환하는 컴포넌트 (외부 변수를 수정하거나, props를 직접 변경하지 않음)" 라고 했는데 제 머릿속에서는 state는 언제든지 변경될 수 있고 props가 어떤 특정한 state값 ( 서버에서 받아온 상품 목록 리스트)이면 결국 해당 props도 변경 될 수 있다라고 생각이 들어서 좀 많이 자세하게 설명을 듣고 이해 하고, 코드를 작성할 때 적용하기 위해 질문을 올립니다. 추가 ctx) 현재 프론트엔드 개발자입니다. 프론트 개발을 하고 있습니다. 언제나 순수 함수 / 순수 컴포넌트 말로 만 듣고 "이런 거겠지" 라고 하며 어물쩡 넘어갔었는데 요번에 확실하게 개념과 이해 그리고 체화 하고 싶어서 질문 남깁니다.
"AI 딸깍의 시대" 원리로 돌파하는 Node.js와 CS Part 2 - 스트림 아키텍처와 하드웨어 통제기
안녕하세요 강의 잘듣고있습니다! 풀스택 개발자를 목표로 하고있고, 원리를 배우는게 너무 즐겁고 큰 도움이 되고있습니다. 그런데 당장 nestjs 및 리액트 등으로 웹서비스 개발업무도 할예정인데 nestjs 는 어떻게 공부를하면좋을까요? T 자형 인재가 되고싶습니다! 그리고 강의듣는 순서도 궁금합니다!! 현재 NODE 듣고있고, 유닉스도 결제했습니다..! NESTJS 도 공부빨리해야하는 상황이네요..
안녕하세요 강의 잘 듣고 있습니다 강의에서 index.html 부분을 설명해주실 때 최신 문법의 js를 사용하고 있어 babel이 jsx를 구버전 js로 컨버팅하는 역할을 수행한다고 설명을 해주셨는데요 node js 로 서버를 호스팅하지 않더라도 로컬 경로의 html이 크롬에서 렌더 되서 보이더라구요 브라우저는 chrome을 사용하고 있는데, 이건 그냥 최신 브라우저들이 jsx를 지원하고 있다고 이해하면 될까요?
다운로드된 수업자료에서 활용 강좌의 완성 예제 깃허브 경로 https://designdigit.github.io/front-portfolio-2025-1 https://designdigit.github.io/front-portfolio-2025-2 로 들어가면 404오류가 뜨고 There isn't a GitHub Pages site here. 이렇게 나옵니다. 정확한 경로를 알려주세요. 그럼 답변기다리겠습니다.
React 마스터 클래스: Part 3 - 실무 핵심 라이브러리 정복 (TypeScript, Zustand, React Hook Form, TanStack Query)
62강 실습 자료로는 ' [Solution] Stale-While-Revalidate: 사용자에게는 캐시를, 뒤에서는 갱신을' 에 관한 내용이 나와야하는데, 현재는 '[Pain] 수동으로 관리하던 전역 로딩/에러 상태가 로직을 오염시킬 때' 로 나와있습니다. 62강 실습 자료 교체 부탁드립니다.
"AI 딸깍의 시대" 원리로 돌파하는 Node.js와 CS Part 2 - 스트림 아키텍처와 하드웨어 통제기
안녕하세요. AI 딸깍의 시대를 1~4 구매하여 수강 중에 있습니다. 강의를 듣다보니, 의문이 들어서 문의드립니다. AI로 딸깍하니, 얕은 수준으로 다루게 되니 원리를 이해하자를 이야기하고자 해당 강의가 있는 것 같습니다. 실무에서는 라이브러리나 프레임워크로 개발을 진행하게 되는 것 같습니다. 원리를 이해하면 개발을 조금 더 잘하게 된다? AI에 명령을 내릴 때 조금 더 잘 내릴 수 있다? 아니면 장애가 터졌을 때 이유를 알 수 있다? 그것도 아니라면 개발 시 장애를 미리 예측하여 대응할 수 있다로 봐야할까요? 보면서 궁금하여 문의드립니다.