원시 데이터 할당 방식

안녕하세요. 말씀주신 내용이 맞습니다. 질문하신 내용과 제가 설명한 내용 사이에 차이점이 있어서 질문해주신걸까요? 아니면 질문인걸까요? 제가 강의 내용이 워낙 많아 어떤 부분에 대한 것인지 헷갈리네요. 만약 강의 내용 중에 제가 이와 다르게 설명했다면 몇 강인지, 몇 분에서 설명이 잘못됐는지 알려주시면 감사하겠습니다.

좋아요 배치 처리 로직과 실제 API 동작 차이에 대해 질문드립니다

안녕하세요 클라이언트단 구현과 서버단 구현은 사실 정답이 있는 주제는 아닙니다. 클라이언트에서 막는 것은 서버까지 가는 요청의 총 숫자를 줄여 원천 차단에 의의가 있지만 반대로 정상적인 활동까지 막을 수도 있습니다. 또는 복잡한 예외 처리가 생길 수도 있겠죠. 제가 강의에서 이야기했는지 제 유튜브에서 얘기 했는지 정확히 기억은 나지 않지만, 대표적으로 farming 게임이 클라이언트단에서 모아서 처리하는 예에 해당합니다. 클래시오브클랜과 같은 게임을 해보셨을지 모르겠으나, 해당 게임은 접속하면 광산에 쌓인 골드를 클릭해 수집하고, 엘릭서를 수집합니다. 사용자의 대부분이 그 활동을 하죠. 아주 극소수의 사용자만 몇몇 광산의 골드와 엘릭서를 누락해서 수집할 수 있지만 대부분은 접속하자마자 그동안 쌓인 자원을 수집합니다. 그게 가장 효율적인 패턴이라 그렇죠. 그럴 때 여러번의 클라이언트 요청이 아닌 모아서 처리하는게 오래전부터 사용됐던 패턴이고, 이를 웹 클라이언트에서도 전략적으로 활용할 수 있습니다. 생각하신대로 서버측에서도 처리해도 괜찮은 전략입니다. DB에 너무 많은 짧은 I/O를 발생시키는 것은 서비스가 커질 수록 치명적일 수 있기 때문에 캐시 서버를 둬서 캐시된 데이터를 일정 사이클마다 처리한다던지 하는 방향으로 해결할 수도 있습니다. 인스타그램에서 테스트해보신 건 매우 좋은 습관입니다. 여러 서비스를 탐방하시면서 어떤 시점에 어떤 요청이 발생하는지, 묶어서 발생하는 경우가 있는지, 지속적으로 보시다보면 더 높은 수준의 자신만의 통찰을 얻으시리라 생각합니다. 감사합니다.

섹션 1 Props collections & getters 제목의 의미가 궁금합니다

안녕하세요, 강좌 제목이 들어가는 부분인데 오타가 들어갔네요. 무시하셔도 됩니다.감사합니다.

배포 관련 내용 추가될 예정이 있을까요?

안녕하세요 Eun님 예정된 강의 추가는 없습니다. 배포는 데스옵스 영역이라고 보고 프론트에서 굳이 다루지 않았습니다. 감사합니다.

학습자료는 따로 공유가 안되는건가요?

안녕하세요 영민님, 강의 설명란에 보시면 나오는데 1강에 강의 자료 링크 있습니다!

이벤트 루프 실행 관련

안녕하세요 동군님. 단순히 배우는 것을 넘어 실제 시스템에서 심도 깊은 이해를 위해 고민을 많이 해보신 거 같네요. 정말 훌륭한 자세라 생각합니다. 질문에 대해 결론부터 말씀드리면 macroTask()는 randeringPipelineTask()가 요청한 브라우저의 페인트(Paint) 작업이 완전히 완료된 후에 실행될 가능성이 매우 높습니다. 이유는 자바스크립트의 이벤트 루프의 명확한 작동 순서 덕분입니다.질문하신 mySchedule 메서드 시나리오를 이벤트 루프 주기 관점에서 분석해 보겠습니다.const mySchedule = async () => { await randeringPipelineTask(); // ① 랜더링파이프라인 (≒ 한 프레임의 작업) await macroTask(); // ② 매크로 태스크 }randeringPipelineTask()가 완료되고 Promise가 resolve될 때까지 JS 엔진은 대기합니다.이 대기 시간 사이에 브라우저는 렌더링 업데이트를 수행합니다.randeringPipelineTask()가 resolve되고, 그 콜백(macroTask()로 이동하는 로직)이 Microtask Queue로 들어갑니다.이 Microtask Queue가 비워진 후, 브라우저는 렌더링 파이프라인(Layout, Paint)을 수행합니다.렌더링이 완료된 후, 이벤트 루프는 다음 Macrotask를 큐에서 꺼내 콜스택으로 넣습니다.핵심은 이벤트 루프는 매 주기마다 반드시 렌더링을 처리한 후에 다음 매크로태스크를 처리한다는 점입니다. 따라서 macroTask()가 다음 주기(cycle)의 Macrotask로 실행된다면, 그 전에 발생해야 할 렌더링 작업은 모두 완료됩니다. 수강생님의 혼란은 "JS 엔진은 부탁까지만 하고 다음을 실행할까?"라는 부분에서 기인합니다. 일반적인 DOM 조작은 '부탁까지만' 하는 것이 맞습니다. 예를 들어, element.remove()를 수백 번 호출해도, 실제 레이아웃 계산과 페인트는 콜스택이 완전히 비워진 후(혹은 requestAnimationFrame 같은 특정 지점)에 단 한 번의 렌더링 스텝에서 배치(Batch)로 처리됩니다. 그래서 이벤트 루프의 표준 주기를 살펴보면JS 엔진: 현재 MacroTask 실행JS 엔진: MicroTask Queue 비우기브라우저: Update the rendering 과정으로 Layout, Paint, Composite 실행이벤트 루프: 다음 MacroTask 선택렌더링은 마이크로태스크가 비워진 후에 이뤄지기 때문에 구체적인 함수에 대해 코드가 있지는 않지만 randeringPipelineTask 함수를 추정해본다면 다음과 같습니다. 만약 randeringPipelineTask()가 다음 렌더링 완료를 기다리는 역할을 하려면, 가장 표준적이고 강력한 방법은 requestAnimationFrame (RAF)과 Promise를 조합하는 것입니다.randeringPipelineTask() 내부에서 DOM을 변경하고, RAF를 요청합니다.RAF 콜백은 렌더링 바로 직전에 실행됩니다.RAF 콜백 내에서 setTimeout(0)이나 다른 Macrotask를 이용하거나, 혹은 Microtask를 한 번 더 사용하여 Promise를 resolve 시켜 다음 프레임 경계를 넘기는 방식으로 페인트 완료 후에야 비로소 randeringPipelineTask()의 await가 해제되도록 구성해야 합니다.결론적으로, await가 걸려있다는 것은 브라우저의 한 프레임(주기) 경계를 넘기도록 설계된 비동기 로직을 사용했다는 의미이며, 이벤트 루프의 설계상 이 경계를 넘으면 렌더링은 이미 완료된 상태입니다. 이러한 이유로 DOM 조작을 빈번하게 해야하는 경우라면, 매우 특수한 경우가 되겠지만! requestAnimationFrame(RAF)MutationObserver: 강의에서는 설명하지 않음setTimeout(0)등을 통해 렌더링 완료를 명확히 확인하실 수 있을 겁니다. 답변이 되셨길 바랍니다. 감사합니다.

이벤트루프 설명에 대한 질문입니다.

안녕하세요. 답변해드리려고 했는데 ai 인턴의 답변이 생각보다 정확하게 답변이 됐네요.강의 자료에서 설명된 내용은 전체적인 자바스크립트의 동시성 모델을 설명하기 위한 개념적 설명입니다. 첨부하신 링크에서 설명한대로 정확한 구성 및 소유 위치는 엔진과 브라우저입니다. 각 구성요소의 위치는 다음과 같습니다.자바스크립트 엔진 (예: V8 엔진)콜스택힙 브라우저/런타임 환경Web API태스크 큐마이크로 태스크 큐이벤트루프 이를 한 문장으로 요약해서 설명하자면 콜스택과 힙은 V8 엔진의 구성 요소이고, 이벤트 루프는 브라우저 환경에서 이 엔진을 감시하고 비동기 작업을 조율하는 별도의 메커니즘 이라고 볼 수 있습니다. 심도 깊은 고민 응원드립니다! 감사합니다.

Map 강의 누락된 것 같습니다.

안녕하세요 모던님, 알려주신 부분은 라이브 강의 부분에서 편집 과정에서 빼는게 좋을거 같아 부드럽지 않게 보이는 것일 뿐 업로드된 영상 내용이 맞습니다. 큰 차이는 없으니 이어서 시청해보셔도 될 거 같습니다. 감사합니다.

Variable Object 질문

안녕하세요, 좋은 질문 남겨주셔서 감사합니다.말씀해주신 대로 Variable Object(VO) 와 Variable Environment(VE) 는 같은 실행 컨텍스트의 동작을 설명하는 개념이지만, 명세가 발전하면서 용어와 구조가 달라진 것입니다. Variable Object (VO) — (ES3, 구개념)실행 컨텍스트가 생성될 때 함께 만들어지는 내부 객체로,var 선언함수 선언함수 매개변수들이 VO에 등록됩니다.실행 컨텍스트의 생성 단계에서 이 값들이 VO에 채워지고,실행 단계에서는 이 VO를 참조하여 식별자를 조회합니다.즉, 당시 명세에서는 스코프를 단일 객체(VO)로 표현했다고 보시면 됩니다. Variable Environment (VE) — (ES5 이후, 현대 개념)VO 대신 Lexical Environment라는 더 정교한 구조가 도입되었습니다.Lexical Environment는 두 가지로 이루어져 있습니다:Environment Record → 실제 변수, 함수, 매개변수가 저장되는 곳Outer Lexical Environment Reference → 부모 스코프를 가리키는 참조 (스코프 체인)이 중 Variable Environment는 특별히 var, 함수 선언, 함수 매개변수를 담는 Environment Record를 의미합니다.let, const 같은 블록 스코프 변수는 별도의 Declarative Environment Record에 관리됩니다.핵심 차이명세의 진화VO는 ES3 시대 개념VE는 ES5 이후 도입된 Lexical Environment 체계의 일부스코프 관리 방식VO는 단일 객체로 스코프 관리VE는 계층적 구조를 가지며 스코프 체인을 통해 관리let/const 처리VO는 let/const 개념이 반영되지 않음VE/Lexical Environment는 이를 위한 별도의 구조를 제공강의에서 VO를 사용한 이유강의에서는 교육적 단순화를 위해 Variable Object 개념을 먼저 사용했습니다.VO는 “실행 컨텍스트가 변수를 모아두는 저장소”라는 감각을 직관적으로 잡는 데 유리합니다.이후 ES2015+ 명세에 나오는 Lexical Environment / Variable Environment 개념을 학습하면, VO로 배운 직관을 그대로 확장할 수 있습니다.정리하면, VO는 이해를 돕기 위한 구개념, VE는 현대 명세의 정식 구조이고,학습 순서는 VO → VE/Lexical Environment로 가는 것이 가장 효과적입니다.

메모이제이션 뒷부분 짤린건가요?

안녕하세요 멀머님, 확인해보니 6분정도 프리메튜어 최적화 부분이 편집 과정에서 누락되어 추가했습니다. 기존에 8분이었는데 14분으로 바뀌었습니다. 알려주셔서 감사드립니다. ps. 추가로 알려주신 Props Collections & Getters, Slot 부분도 확인해서 반영해두겠습니다.