TS, 리액트 강의중에 뭘 먼저 수강하는게 좋을까요?

안녕하세요 cadenzza님 이정환입니다.타입스크립트를 이용해 React.js가 아닌 Nest.js(Next.js 아닙니닷)나 Express.js 등의 기타 프레임워크를 사용하실 예정이라면 타입스크립트부터 수강하시는걸 추천드리고,그렇지 않고 React.js를 꾸준히 사용하실 예정이라면 React.js를 선 수강하시는걸 추천드립니다.

할인쿠폰 관련하여

안녕하세요 썹th님 이정환입니다.아이고! 죄송합니다 25년 말에 쿠폰 교체해야 된다는걸 깜빡했습니다 ... ㅠㅠ즉시 교체해 두었습니다! 다시 확인 부탁드립니다 😃

이미지 메모리 누수 관련 질문

안녕하세요 keeenco님 이정환입니다.너무 좋은 질문을 주셨네요! 답변드리겠습니다 😀 1) 실제로 메모리 누수가 발생하는지 확인하는 방법메모리 누수를 확인하시려면, 브라우저의 개발자 도구를 이용하셔야 합니다.보통 개발자 도구의 Memory 탭을 사용하는데요, 생각해보니 브라우저 MCP를 통해 AI가 테스트를 도와줄 수 있을지도 모르겠습니다 ..! 참고해보시면 좋을 아티클 하나 추천해드립니다.https://blog.eunsukim.me/posts/debugging-javascript-memory-leak-with-chrome-devtools 2) 학습 태도 관련 질문사실 메모리 누수 등의 최적화 관련 이슈는, 프로젝트 개발 도중 직접 경험해보지 못했다면 알아차리기 어렵습니다. 보통은 나만의 프로젝트를 만들어보다 "어 여기 왜이렇게 느리지!?" 라는 느낌을 받는 것 부터 출발하게 되거든요그래서 수동적인 태도로 잘못 학습하시고 있다는 마음보다는 내가 "아직 겪어보지 못한 문제가 많구나 더 많은 경험을 해 보자!" 라고 편하게 마음 가지시는걸 추천드립니다 😀AI에게 도움을 받을수도 있을 것 같아요! 컨텍스트가 초기화 된 별도의 세션에 프로젝트를 직접 실행해보며 여러 방면으로 검토해 달라고 부탁해보셔도 좋을 것 같습니다 (제가 자주 활용하는 방식이에요!)

56강 alertModalStore 구현 중 질문

안녕하세요 이정환입니다.~/src/store/alert-modal.ts 파일의 해당 단언을 지우신 다음,~/src/components/modal/alert-modal.tsx 파일을 확인해보시면아래 그림과 같이 store 내부의 State 프로퍼티들을 잘 추론하지 못하는 걸 확인하실 수 있습니다.(사진)이렇게 되는 이유는 State 타입이 유니온(Discriminated Union)으로 정의되어 있어서, isOpen이 false일 때(CloseState)에는 title, description 등의 프로퍼티가 아예 존재하지 않기 때문입니다. type State = CloseState | OpenState;그런데 combine과 devtools 미들웨어를 거치면서 이 유니온 구조가 제대로 보존되지 않아, isOpen을 기준으로 한 타입 좁히기가 정상적으로 동작하지 않게 됩니다. 쉽게 말해 isOpen이 true라면 State에 title, description 등의 프로퍼티가 존재한다고 추론되어야 하는데 그렇지 못하고 있는 상황입니다.따라서 as typeof store & State 단언문을 추가하여, 자동으로 추론된 Store 타입(typeof store)에 State 타입을 교집합으로 묶어준 것입니다.

vs code 자동완성관련 문의

안녕하세요 이정환입니다.VSCode의 자동완성은 가끔 사람을 짜증나게 하죠 ... ㅋㅋ 공감됩니다.사실 강의에서도 몇번 자동완성으로 인해 NG가 발생한 부분도 많습니다 (물론 다 편집되었습니다)말씀하신 것처럼 .이나 ( 같은 특수 문자를 입력할 때 자동완성이 강제로 적용되는 문제는 VSCode 설정 때문입니다.이를 해결하시려면 VSCode 설정에서 다음을 변경하시면 됩니다:Ctrl + , (Mac은 Cmd + ,) 눌러서 설정 열기검색창에 Accept Suggestion On Commit Character 검색"Accept Suggestion On Commit Character" 체크 해제(사진)이렇게 하면 .이나 (를 눌러도 자동완성이 강제로 적용되지 않습니다!또는 settings.json에 직접 추가하셔도 됩니다:{ "editor.acceptSuggestionOnCommitCharacter": false }

checkbox 캐시 update

안녕하세요 이정환입니다.체크박스를 변경할 때 캐시 데이터를 업데이트하지 않으면 화면이 전혀 바뀌지 않습니다.React Query는 mutation이 성공적으로 서버에 요청을 보내고 응답을 받아도, 자동으로 캐시를 업데이트해주지 않습니다. 서버의 데이터베이스에는 체크박스 상태가 변경되지만, 화면에 표시되는 데이터는 여전히 캐시에 저장된 이전 데이터를 보여주는 거죠.체크박스 변경이든 내용 수정이든 상관없이 화면에 변경사항을 반영하려면 반드시 캐시 데이터를 업데이트해야 합니다. 캐시 업데이트 없이는 서버에만 변경사항이 저장되고 화면은 그대로 유지됩니다!

91강 useEffect내에서 상태변화함수 호출시 발생하는 에러

안녕하세요 김김님 이정환입니다.이 경고는 useEffect 안에서 setState를 직접 호출할 때 나타나는 React의 새로운 lint 경고입니다. 작동은 정상적으로 되지만, 성능 이슈나 무한 렌더링을 유발할 가능성이 있어서 경고를 띄워주는 거죠.만약 경고 메세지를 제거하고 싶으시다면 eslint.config.js 파일에 다음 rules를 추가하시면 됩니다. "react-hooks/set-state-in-effect": "off",이 경고는 비교적 최근에 추가된 규칙이라, 강의를 촬영할 당시에는 없었거나 덜 엄격했을 수 있습니다. 혼란을 겪으시는 분들이 계실수도 있으니 안내 메세지를 추가해 두겠습니다 ..!

프론트엔드에서의 인터페이스활용

안녕하세요 이정환입니다.우선 프론트엔드에서는 백엔드(Spring Boot 같은)만큼 DI나 클래스 기반의 객체지향 프로그래밍을 많이 사용하지 않습니다. 그래서 말씀하신 것처럼 인터페이스를 구현해서 다형성을 활용하는 경우가 많지는 않습니다.TypeScript의 인터페이스는 타입 정의용으로는 엄청 많이 쓰이지만, Java처럼 DI를 통해 구현체를 교체하는 용도로는 거의 사용하지 않습니다. 가장 큰 이유는 React가 함수형 프로그래밍 패러다임을 따르기 때문입니다. 데이터와 로직을 분리해서 함수로 조립하는 방식이 훨씬 자연스럽고, 백엔드처럼 복잡한 비즈니스 로직이나 트랜잭션 처리가 많지 않습니다. 대부분 UI 렌더링과 상태 관리가 주된 작업이기 때문에 클래스 기반의 무거운 구조가 필요하지 않은 거죠.그럼에도 불구하고 클래스를 사용하는 경우가 있는데, 바로 브라우저 API 같은 외부 API를 추상화할 때입니다. 예를 들어 LocalStorage를 직접 쓰지 않고 StorageService 같은 클래스로 감싸서 사용하면, get, set, remove 같은 여러 관련 메서드를 하나로 묶을 수 있고, 테스트할 때 Mock 객체로 교체하기도 쉬워집니다. API 클라이언트도 마찬가지로 baseURL 같은 상태를 가지고 있어야 하고, get, post, put, delete 같은 관련 메서드들이 있기 때문에 이런 경우에는 또 클래스로 만드는 게 적합합니다!PS. JavaScript와 TypeScript는 멀티 패러다임 언어이기 때문에, 상황에 맞게 함수형과 객체지향을 섞어서 사용할 수 있습니다. 다만 프론트엔드에서는 함수형이 주가 되고, 필요한 부분에만 객체지향을 활용하는 방식이 일반적입니다!

87강 필터 함수 질문

안녕하세요 이정환입니다.코드의 가독성만 따진다면 말씀하신 대로 연도와 월을 직접 비교하는 방식이 더 읽기 쉬운 건 맞아요! 그러나 우리 강의에서 사용되는 item의 createdDate는 타임스탬프로 보관되어 있습니다. 따라서 이 방식을 쓰려면 모든 아이템의 createdDate 타임스탬프를 매번 Date 객체로 변환해야 합니다.이렇게 하면 아이템 개수만큼 Date 객체가 생성되기 때문에, 데이터가 많아질수록 비효율적이에요. 반면 강의에서 사용한 방식은 시작 시간과 끝 시간을 미리 타임스탬프로 만들어두고, 숫자끼리 비교만 하면 되기 때문에 변환 과정 없이 바로 필터링이 가능합니다.데이터의 개수가 작다면 말씀하신대로 비교해도 깔끔하게 처리 가능하지만, 데이터의 개수가 많아질수록 비 효율적인 방식이 될 수 있기에 속도가 빠른 숫자간의 연산을 사용하기 위해 강의에서는 이렇게 안내드리고 있습니다

useRef, useState count 비교

안녕하세요 tjsgh9352님 순서대로 답변드릴게요 1번 질문결과적으로는 맞습니다. 그러나 더 엄밀히 따지면 다음의 순서대로 동작합니다.컴포넌트 리렌더링은 함수가 종료된 이후에 일어난다는것이 핵심입니다countRef.current의 값 증가setInput 함수 호출 -> State 업데이트컴포넌트 리렌더링 2번 질문네 맞습니다. 이때 참고로 만약 같은 이벤트 핸들러(onChange) 내에서 setInput을 두번 호출해 textarea의 값과 count를 각각 변경했다고 하더라도 리액트는 이를 합쳐서 처리합니다. 따라서 리렌더링은 이럴 경우에도 한번만 발생합니다. 자세한 내용은 아래의 공식문서를 참고해보시면 도움이 될 것 같습니다.https://react.dev/learn/queueing-a-series-of-state-updates 3번 질문네 맞습니다. 결과적으로는 그렇다고 볼 수 있습니다.