useEffect 의존성 질문

안녕하세요 dev.mingyo님. 영상에서 useEffect 의존성 배열에 path 를 넣은 것에 대해 질문 주셨네요. 결론부터 말씀드리면, 안 넣는 것이 맞습니다. 부수 효과는 "popstate" 이벤트 핸들러를 등록하는 역할이고요. path는 history 객체에 전달하는 용도로 사용되는데요, 마운트 시점의 값으로도 충분해서 한 번만 실행되어도 됩니다. 오히려 path를 의존성으로 전달하게되면 path 변경에 따라서 이벤트 등록/해지 과정이 불필요하게 반복되는 낭비가 있긴해요.영상에서는 놓쳤지만, 실습 코드에서는 의존성이 없는 점도 참고해 주시면 수업을 따라오시는 데 덜 헷갈리실 것 같습니다.

잘못된 useEffect 사용?

안녕하세요 dev.mingyo님. 리액트의 핵심원리를 날카롭게 지적해 주셨네요.결론부터 말씀드립니다. 네, 맞습니다. 해당코드는 useEffect를 오용한 사례가 맞습니다. 불필요한 렌더링리액트는 상태가 변하면 렌더링을 수행하는데요. 사용자가 값을 입력 함 → setValue 호출 (1차 렌더링)렌더 직후 useEffect 실행 → setErrors 호출 (2차 렌더링)한 번만 입력해도 브라우져는 매번 두 번씩 화면을 그리는데요, 서비스가 커질수록 성능 저하의 원인이 될수 있습니다.개선 방향 errors 상태를 두었지만 실은 values를 통해 파생될수 있는 값입니다. 공식 문서에서 강조하듯, 기존 상태를 조합해서 만들 수 있는 값은 별도의 상태로 두지 않는 것이 유지보수에 훨씬 유리해요. errors를 직접 렌더링 내의 변수로 선언하는 것이 '리액트다운' 해결책입니다.// ❌ 기존 방식: 불필요한 렌더링 발생 // const [errors, setErrors] = useState({}); // useEffect(() => { setErrors(validate(values)) }, [values]); // ✅ 파생된 상태로 처리 (useState/useEffect 제거) const errors = validate(values);이렇게 작성하면 values가 바뀔 때 리액트가 렌더링을 시작하고, 최신 errors 값을 계산하여 화면에 그립니다. 코드도 훨씬 간결해지고 성능도 최적화될 수 있습니다.

orderableProductItem 에 관하여...

안녕하세요 컴포넌트 구조에 대한 질문을 주신것 같네요. 컴포넌트는 어플리케이션이 성장하면서 그 구조도 달라질수 있는데요. ProductItem과 OrderableProductItem을 이러한 관점으로 이해하시면 좋습니다.상품 상세: ProductItem으로 상품 정보와 주문하기 버튼을 렌데링합니다. 이후 장바구니에서도 비슷한 UI를 렌더 하는데요. 상품 상세와 비슷해 ProductItem을 재사용하려는 판단에서 시작합니다.장바구니: 상품상세에서는주문하기버튼이있지만장바구니에서는없어서이러한조건부렌더링을 ProductItem 역할로두었습니다. 상품상세에서는버튼까지렌더하도록조합할수있고요(onClick 전달). 장바구니에서는버튼이렌더되지않도록사용할수있게됩니다(onClick 생략). 마지막엔가독성을위해서이러한조합으로 OrderableProductItem이란컴포넌트를신설한것입니다.

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

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

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: 리액트 컴포넌트 상태 변경 → 리렌더 유발