강의 자료, 블로그, 깃 주소

강의 본문에 링크가 제대로 연결되어 있지 않았네요. 샘플 어플리케이션 코드 | 깃헙요구사항 문서 | 깃헙강의 노트 | 김정환블로그본문도 수정해 두었습니다.

React 훅 구현 원리와 실무 패턴 관련 질문 (useState, useEffect 순서 및 핸들러 구조)

기능을 구현하다보면 상태가 늘어가는 경우는 빈번한데요. 이때 상태 관리로 인해 파생되는 핸들러나 이펙트도 늘어나 코드 관리가 어려운 순간이 있습니다. 이에 대한 질문을 주신 것 같아요. 저는 상태 관리가 많아져 한 컴포넌트에서 관리하기 어렵다면, 별도의 역할을 하는 컴포넌트로 분리하거나, 커스텀 훅으로 분리해 사용합니다. 관련된 리액트 앨리멘트 반환로직까지 컴포넌트로 분리한다면, 이를 JSX 문법으로 간편히 가져다 사용할수 있을겁니다. 커스텀 훅으로 분리한다면, 추상화 계층으로 복잡한 로직을 숨기고 컴포넌트에서는 이를 통해 관련된 상태와 핸드러를 제공 받을 수 있어요. 다른 사람이 작성한 코드를 많이 보고, 여러 번의 시행착오 경험을 겪으면 균형잡힌 컴포넌트 설계 기법을 갖추실 수 있을거에요.

지금 시점에서 해당 강의를 듣는 것에 대하여

안녕하세요, 강의 수강 관련해 문의 주셔서 감사합니다.최신 개발환경에 비해 수업에서 사용하는 라이브러리 버전이 맞지 않긴합니다. 하지만 버전과 무관한 기본 원리에 대한 내용을 배우실수 있을 거에요. 개념을 탄탄히 이해하고 나시면 다른 도구를 만나더라도 훨씬 자신감 있게 다루실수 있을 겁니다. 이와 관려한 후기들도 올려주셨는데요, 참고해 보시면 강의 수강을 결정하는 데 도움이 되실 것 같습니다.https://inf.run/8XzcVhttps://inf.run/2N6rehttps://inf.run/VSRZc

리액트 1,2부 이후 후속 강의나 준비 중인 다른 강의가 있으신가요?

강의를 좋게 평가해 주셔서 무척 고맙습니다. 리액트1부 강의를 마치셨다면 2부로 넘어가셔서 훅과 고급 주제를 학습하시길 추천 드립니다. 웹 개발의 기초 지식 중에 HTTP를 이해하고 익히는 수업이 있는데 이것도 같이 수강하시면 도움이 될거에요. https://inf.run/GFc3Z

브라우저 내부 보안 정책 스코프에 대한 질문

좋은 질문입니다. 이 내용은 HTTP 보안정책의 브라우져 내부 동작 원리에 해당되어, 수업 범위를 약간 넘어가긴 합니다. 방향을 잡을 수 있다록 핵심만 말씀드릴게요.브라우져의 보안 정책은 일반적으로 Origin 단위로 적용됩니다.단, 말씀하신대로 쿠키는 조금 넓은 단위로 적용됩니다.브라우져별로 세부 동작이 조금씩 다를수 있을 것 같습니다.

실무에서 웹개발자가 명시적으로 선언하는 보안 정책의 범위 및 보안 정책 설정 위임 라이브러리

Express.js를 예로 들면CORS: cors 공식 미들웨어를 통해 손쉽게 설정할 수 있습니다.예를 들어 app.use(cors({ /* 설정 옵션 */ }))쿠키 보안 속성: 프레임워크 자체의 res.cookie() 같은 API로 설정할 수 있습니다.CSP 헤더는 주로 서버 레벨(Nginx, CDN)이나 빌드된 HTML을 반환하는 구간데서 설정합니다.Express 환경이라면 helmet 같은 미들웨어를 통해 대부분의 보안 헤더를 쉽게 추가할 수 있습니다.

pushState로 주소를 바꾸면 렌더링이 안 되는 이유가 궁금합니다.

pushState는 브라우져의 히스토리 상태만 변경합니다. 리액트 컴포넌트는 이 상태와 전혀 상관없는 객체이고요. 그렇기 때문에 별도의 리액트 상태(path)를 두었는데요. 이를 변경해 리액트 컴포넌트가 다시 그려지도록(리렌더) 의도한 것입니다.정리하면,pushState: 히스토리 상태 변경 setState: 리액트 컴포넌트 상태 변경 → 리렌더 유발

2025년 기준 번들러 트렌드와 선택 기준이 궁금합니다 (Webpack, Vite, tsup 등)

정말 깊이 있는 질문을 주셔서 감사합니다. 말씀하신대로 요즘은 웹팩 뿐만 아니라 다양한 번들러가 나왔고 프로젝트마다 사용하는 도구가 다르긴 합니다. 최근에는 Vite가 거의 표준처럼 자리잡았다고 봅니다. 대부분의 신규 프로젝트에서 이 도구를 사용하고 있는데요. 개발 서버 속도가 매우 빠르고, 개발/프로덕션 빌드에 각 각 다른 번들러를 사용해 안정성도 유지하는 구조 덕분이라고 생각합니다. UI 컴포넌트 라이브러리, 예를 들어 디자인 시스템이나 내부 공용 컴포넌트를 제작할 때는 Rollup을 가장 많이 사용하고요. 오래된 프로젝트라면 여전히 웹팩을 많이 사용하고 있습니다. 다양한 생태계의 이점도 있고 수년간 유지해온 설정으로 쉽게 바꿀 수는 없더라고요. 강의 내용이 최신 트렌드와 다소 차이가 있긴해요. 하지만 "번들러의 동작 원리"를 이해하고 직접 최신 도구에 적용하는 과정에서 크게 성장할수 있다고 생각합니다. 실무 감감을 키우는 방법이기도 하고요. 소중한 의견 남겨주셔서 매우 감사합니다.

ETag 사용시 서버의 성능 향상

ETag를 활용한 캐싱 기법은 브라우져와 서버 모두 성능 향상에 영향을 줄 수 있습니다. 브라우져에서는 ETag를 이용해 이미 다운로드한 파일을 재사용함으로써 네트워크 요청을 덜 보낼 수 있습니다. 말씀하신대로 네트워크 대역폭을 아낄수 있어요.서버는 If-None-Match 요청헤더 값을 확인 한 뒤, 요청한 리소스와 같은 값이라면 "즉시" 응답을 보냅니다. 만약 이 값이 다르다면, 서버는 "리소스를 읽고 이를 응답 본문에 실어야"하는데요. ETag를 사용하면 이러한 서버 리소스를 아낄수 있는 이점이 있습니다.

super.show() 호출하는 이유가 궁금합니다.

부모 클래스의 show() 메소드를 호출하지 않아도 동작하는데요. 이는 SearchFormView가 화면에서 사라진(hide() 메소드 호출)적이 없이 때문입니다.그래도 부모 메소드를 오버라이딩하는 경우에는 부모의 메소드를 호출해 주는 것이 좋습니다. 부모 View 클래스는 css 속성 display를 변경하면서 화면의 노출여부를 제어하는 hide()와 show() 메소드를 제공합니다. 이를 상속한 자식 클래스 SearchFormView는 이 메서드를 이용해 화면에 숨기고 노출할 수 있는데요. 이런 효과를 얻으려면 부모의 메소드를 호출해 주어야합니다. 비슷한 질문super.show()에 대해 질문드립니다