강의 난이도에대해서

어려운 부분이랑 쉬운 부분이 섞여있어요. 어려운건 다들 어려운가보다- 하면서 가볍게 듣고 넘기면서 학습하세요. 나중에 다시 들어보시면 성장의 기쁨을 느끼게 되실지도! :)

강의자료 관련 질문

안녕하세요깃헙 코드는 공개하지 않고 있습니다.완성본, 보일러플레이트 중 하나의 파일을 다운로드받아 설치하시면 됩니다.

게시판 리스트 만들때 어디부터 use client를 적용할 지 모르겠어요

어떻게 답변을 드려야 좋을지를 고민하느라 답이 늦었습니다. 우선 먼저 말씀드리고 싶은 것은, 대부분의 고민 되는 문제에는 정답이 없다는 것입니다.그렇기 때문에, 다양한 관점에서 문제를 바라보고, 여러 가지 해결책을 모색하는 것이 중요합니다. 질문 내용을 보면, 직접 말씀하신 두 안에 따라 작성해 보신 다음 비교해보는 데에 큰 노력이 필요한 것은 아닌 듯 합니다.만약 프로젝트의 규모가 크고 복잡해서 두 안을 테스트 하기가 어렵다면, 작은 프로토타입을 만들어서 두 가지 접근 방식을 시도해 보는 것도 좋은 방법입니다.이를 통해 질문자님의 '생각', 즉 '추정'이 참인지 아닌지를 검증해볼 수 있을 것입니다. 제 생각에는 1안에 따라 zustand에서 '통으로' 관리한다고 해서 반드시 '하나가 바뀌면 전부 렌더링된다'는 결론이 나올 것 같지 않습니다.반면 2안에 따르더라도 zustand에 통으로 넣지 못한다는 것도, 질문 주신 프로젝트의 구체적인 코드 상황을 보지 않은 저로서는 반드시 그런지 알 수가 없네요.그렇기 때문에, 두 가지 접근 방식을 모두 시도해 보고, 실제로 어떤 방식이 더 효율적인지 확인해 보시는 것이 좋겠다는, 다소 원론적인 답변밖에 드릴 수 없을 것 같습니다. 저는 제법 오랜 기간 개발 일을 하고 있는 일개 개발자일 뿐이어서, "일반적인 구현 방식은 이렇다"라고 단정할 만큼 개발 업계 전반의 개발 방식을 두루 파악하고 있지 않으며, 세상 어느 누구도 그렇게 할 수는 없다고 생각합니다.그렇기 때문에, 질문자님께서도 본인의 프로젝트에 가장 적합한 방법을 찾아가는 과정이 중요하다고 생각합니다. 다만 말씀하신 '일반적인 구현방식'이 보편적인 개발 패턴이나 트렌드를 의미한다면,제가 생각하는 일반적인 목록 구현 방식은 다음과 같습니다.서버에서 목록 데이터를 한 벌로 가져와서 사용합니다. zustand로 상태를 관리할 수도 있고, 서버 상태 관리(예: react-query, SWR 등)를 사용할 수도 있습니다.목록의 각 항목 내용이 실시간으로 자주 변경되는 경우, 각 항목에 대한 네트워크 요청을 별도로 관리하여, 변경이 필요한 항목만 업데이트합니다.SEO나 서버 사이드 렌더링, 초기 렌더링 속도 및 렌더링 대상의 최적화는 위 내용과는 별도의 이슈입니다.

Tooltip-useSyncExternalStore()에 함수 넘기는 방식에 대해...

useSyncExternalStore의 두번째 인자(getViewportRect)를 참조로 바꾸고자 했던 사유는함수의 실행값으로 인자를 넘기게 되면 리렌더시 매번 새로운 클로저 함수가 생성될테니(=stored 변수가 계속 초기화 될테니) 생각하지 못한 sideeffect가 있지 않을까? 해서 였습니다.아뇨, 처음 컴포넌트 렌더링 시에 한 번만 실행됩니다. 이는 useState에 전달하는 initialState에 '함수'를 전달하는 경우와 비슷한 맥락으로 이해하시면 됩니다.https://ko.react.dev/reference/react/useState#parameters(사진)

강의 연장관련

https://inf.run/69VLs링크 참조해서 메일 주세요~!

Tooltip-useSyncExternalStore()에 함수 넘기는 방식에 대해...

1. 둘은 사실상 거의 비슷합니다.1) getViewportRect를 클로저가 있는 함수로만 작성 / useSyncExternalStore 내부에서 함수 호출: 이렇게 하면 ViewportContextProvider 컴포넌트를 처음 렌더링할 때 한 번 getViewportRect 함수를 실행하고, 이후로는 다시 실행하지 않습니다. 서버에서 한 번, 클라이언트에서 한 번 실행됩니다. 2) getViewportRect를 즉시실행함수로 작성 / useSyncExternalStore 내부에서는 결과함수 전달: 이렇게 하면 위 파일을 import할 때 즉시실행함수가 실행됩니다. 마찬가지로 서버에서 한 번, 클라이언트에서 한 번 실행됩니다. 즉, '최초 한 번 실행되는 시점'에서는 차이가 있지만, 이후로는 완전히 동일하게 동작합니다.저도 아마 강의 중 어디선가 즉시실행함수로 고쳤던 것으로 기억해요 ㅎㅎ 2. 의존성 배열에 언제나 참조형 데이터를 지양해야 하는 것은 아닙니다.useViewportRect 는 내부 프로퍼티 중 하나라도 변하면 무조건 새로운 객체를 생성하도록 하고 있습니다. 즉 내부 프로퍼티만 달라지는 것이 아니라 객체 자체가 다른 객체로 바뀝니다. 따라서 내부 변수를 하나씩 풀어서 의존성 배열에 넣지 않더라도, 변경사항이 발생할 때마다 useEffect가 잘 실행될 것입니다. 내부 프로퍼티가 달라지더라도 새로운 객체를 생성하지 않고, 기존 객체에 내부 프로퍼티만 변경하도록 작성한 경우라면, 말씀하신 대로 객체를 의존성 배열에 넣었을 때 변경사항을 제대로 감지하지 못할 것입니다. 강의자료는 강의 커리큘럼 맨앞에 있어요 :)

textarea 에서 body 무한깜빡현성 질문 드립니다.

강의자료부터 문제가 있나 싶어 내려받아 실행해보았는데, 강의자료의 코드를 실행했을 때는 같은 현상이 발생하지 않고 있네요.말씀하신 현상만 보면 어디선가 계속 업데이트 되고 있다는 추측은 참일 가능성이 높아 보이지만, 그게 어디서 발생하는지를 질문 내용만으로 유추하기가 어려워 보입니다.업데이트 발생 원인이 리액트 때문인지를 좀 더 직관적으로 알아볼 수 있는 방법이 있습니다.리액트 개발자도구에서 다음 그림처럼 체크하시면, 화면에 변경사항이 박스로 표시되어요.(사진)이걸로 한 번 더 테스트해 보시고, 그래도 안되면 질문자님의 코드를 공유해 주세요.함께 살펴보시죠.

닫힌 상태에서 문자열은 찾아지는데 열리진 않아요

검색기능은HTML details로 작성한 코드이거나hidden="until-found" 속성을 부여한 상태에서 "beforematch" 이벤트핸들러로 toggle 함수를 실행시키도록 한 코드두가지 방법에서만 동작합니다.나머지 다른 아코디언 컴퍼넌트에서는 아코디언이 열리지 않는 것이 정상이에요.제대로 동작하지 않는다면 디버깅을 해봐야겠죠.useEffect 안에서 descRef가 있을 때 이벤트리스너를 등록해주도록 했는데,descRef가 있는지부터 출력을 해보세요.만약 DOM 요소가 출력되지 않는다면 어디선가 오타가 있었을 확률이 있을 것입니다.

질문있습니다 !

어디를 말씀하시는건가요? 저는 말씀하신 내용이 어디있는지 못찾겠어요https://github.com/roy-jung/api-practice/blob/ts-ch3/package.jsonhttps://github.com/roy-jung/api-practice/blob/ts-ch3/server/package.jsonhttps://github.com/roy-jung/api-practice/blob/ts-ch3/client/package.jsonhttps://github.com/roy-jung/api-practice/blob/ts-ch6/package.jsonhttps://github.com/roy-jung/api-practice/blob/ts-ch6/client/package.jsonhttps://github.com/roy-jung/api-practice/blob/ts-ch6/server/package.json

scrollSpy 바닐라버전에서 data-index를 찾는 코드 질문

closest로 충분합니다!다른 메서드도 소개하고 싶어서 억지로 끼워넣어 봤어요 ㅎㅎ차이라면 e.composedPath는 발생한 이벤트에서 바로 메서드를 적용하는 것이고,e.target.closest는 이벤트가 발생한 요소에서 찾는 것이죠.closest는 내부에 지정한 선택자에 해당하는 상위 요소를 탐색하는 명령이니 매 번 새로 탐색을 할 수밖에 없죠.반면 e.composedPath는 이벤트 객체에 처음부터 담겨 있는 '버블링할 대상들'을 배열로 반환해주는 메서드라서 노드를 다시 탐색하지 않을 것이라 추측합니다. 제 추측이 맞다면, e.composedPath가 성능상 아주 약간이나마 이점이 있을 것 같네요.