@josehp_han 메모 넣으면 만능인것 처럼 설명하는게 많아서 기계적으로 댓 달았네요. 메모보단 컴포넌트 구조, 상태관리 시 추가,삭제가 아닌 재할당 행위 줄이기 key값 유니크하게 관리하기 등 리렌더 줄이는대 더 도움되는것들이 많은대 그거 설명하는 사람 본적이 없어요.
강의 영상을 찍을 때 어려움이 이런 부분입니다. 모든 경우도 모든 상황도 스펙에서 당연히 고려해야하는 상황 중 하나라도 빠져면 이런 댓글이 달리고, 그러면 저는 마치 만능으로 이걸 설명한 사람이 되는거죠. 영상 처음부터 보시면 아시겠지만 이런 식으로 줄일 수 있다고, 당연하게도 라이브 데이터 말씀하셨는데 라이브가 실시간 반영되어 렌더링 되는 요소라면 애초에 메모이제이션이 왜 필요할까요. 저는 제 영상에서 빠진 내용보다 댓글에서 지적을 하실 때 영상 찍는 사람 입장도 생각해보셨으면 하네요.
리액트 랜더링 과정 1. render, 2. commit에 대한 컨텐츠도 올려주시면 감사하겠습니다. state를 변경할 때 가끔 왜 바로 화면에 적용이 안되고 한텀 뒤에 랜더링되서 보이지? 하는 경우가 있는데 아마도 2. commit이라고 말씀하신 부분을 이해하지 못해서 그렇게 느끼는거라고 의심이 드네요....
좋은개념 너무 감사합니다. Api 호출 여러번되는거같아서 인지는했지만 개발속도에만 집중하느라 신경을 못썼는데 좋은거 배워갑니다. 혹시 useCallback만 사용하면되는 경우는 어떤경우인가요? Render phase에 영향안끼치는 경우라 생각들어 함수가 props나 state가 아니면 될것같은데 그럴때라면 굳이 useCallback자체를 안써도될것같다는 생각이드는데 제가생각못한 다른경우도있나요? 아니면 제 사고과정에 문제가있나요?
useCallback은 컴포넌트 내에서 함수가 선언된 것에 대해서 메모이제이션하는 기능이기 때문에 함수가 커서 재선언을 방지하는게 효율이 좋다면 사용하면 됩니다. 가령 부모 컴포넌트에 속한 함수가 있을 때 부모 컴포넌트에서 유발된 리랜더링이 거의 없는 상태라면 굳이 useCallback으로 묶을 필요가 없습니다. 도리어 메모리 낭비가 될 수 있겠죠. 반면 함수가 작을지라도 부모 컴포넌트 내에서 다른 이유로 리랜더링이 발생하고 있고, 이에 따라 함수도 재선언되어 이를 참조하는 컴포넌트들이 많은 상태라면 useCallback을 사용하는게 좋습니다.
@@공민제-h6k 단순히 1이다 2다 말할 수 는 없을 것 같습니다. 정확히 얼마의 메모리가 매번 사용되는지는 리액트 소스코드를 뜯어 분석하는 수준이 되어야 할 것 같고, useCallback의 로직이 단순히 메모이제이션을 해두진 않을 겁니다. 비슷한 예로 useState도 단순한 게터, 세터로 구성된 것 같지만 그 안에 로직은 훨씬 복잡하기 때문이죠. 또한 감싸려는 함수마다 비용도 각자 다를 것입니다. 단순 렌더링 과정에서 재선언이 이뤄졌다면 그 과정에서 즉각적으로 가비지 컬렉팅이 됐는지 안됐는지 확인하기 전까지는 모르죠. 이러한 이유에서 useCallback의 성능을 측정할 때는 반복 횟수를 극단적으로 높여서 비교를 하게 되고, 안에 들어간 함수에 따라서도 결과의 차이는 존재합니다. 그러므로 단순히 메모리 1칸 정도로 계산할 수는 없다고 봅니다.
@@josehp_han 03:57 에서 "컴포넌트 함수(App 함수) 내부에 선언된 함수나 값은 컴포넌트 함수가 다시 실행(리랜더링) 될 때마다 새롭게 선언되기에 자식도 리랜더링이 발생하고 이를 막기 위해 useCallback을 사용한다." 라는 설명에서 재선언을 막는 또 다른 방법으로 App() 컴포넌트 함수의 외부에 변수 또는 함수를 선언하여 변수(함수)가 새롭게 선언되지 않도록 하는것이 더 좋은 방법이 아닐까 생각이 들어 질문드렸습니다. (단, 함수 내부의 변수에 접근할수 없으므로 함수 내부 변수를 의존하지 않는 케이스로 한정했습니다.)
네 영상에서처럼 부모컴포넌트에 해당하는 App.js의 리랜더링이 하위 컴포넌트에 리랜더링을 유발한 모습입니다. 정확히 표현하자면 리랜더링 조건이 state, props 뿐 아니라 부모 컴포넌트의 리랜더링이기도 말할 수 있겠지만, 부모 컴포넌트 입장에서 보면 리랜더링을 하면서 자녀 엘리먼트라는 엘리먼트 생성함수를 다시 선언하고 호출한 격입니다. 그렇기 때문에 자녀 엘리먼트 기준에서는 3가지 기준이 될 것이고, 리액트라는 시스템의 기준에서는 최상위 엘리먼트부터 state, props의 변화에 따라 리랜더링이 발생하며, 그 과정에서 하위 컴포넌트는 리랜더링으로 볼 것이냐 랜더링으로 볼것이냐의 차이가 될겁니다. 사실 크게 의미없는 분류긴한데 자세히 설명드렸습니다.
@@josehp_han Strict mode를 켜도 updated 콘솔만 이상하게 한번찍히네요.. 이것보다 다른 중요한 궁금점이 있습니다. ManyRenderingComponent가 재랜더링 되는 이유는 onClick 함수때문이 아니라 App.js에 있는 setState(1) 때문에 리랜더링 되는거 아닌가요? onClick() 함수를 메모함으로 인해서 리랜더링이 방지되는 구조라면 onClick 함수를 제거하고 props가 존재하지 않으면 리랜더링이 되지 않아야 한다고 생각합니다. 입문자라 질문이 이상할 수 있는데 너무 이해가 안되서 질문 드립니다 ㅠㅠ
Use strict가 아니라 react strict mode가 있으면 2번 발생합니다. 똑같이 구현하시려면 cra로 만든다음 제 코드 똑같이 구현해보시면 어떤 의미인지 아실 수 있을 것 같아요! 두번째로 onClick은 커밋 페이즈를 줄여준거고 부모 엘리먼트의 상태 변경으로 인해서 불필요하게 자녀 앨리먼트도 리랜더링이 되는거라 useCallback하고 React.memo로 감싸서 리랜더링을 방지해주는 겁니다 😅 그래서 영상에서 onClick을 콜백으로 감싸줘도 여전히 리랜더링 되는게 확인되실겁니다!
Props를 제거했는데도 리랜더링이 생기는 이유를 더 설명드리자면 자녀 엘리먼트를 고정된 HTML이라고 보시면 안됩니다. 영상 중반에 나온것처럼 리액트 컴포넌트 함수는 React.createElement를 최종적으로 리턴하는 함수라보시면 됩니다. 부모 엘리먼트에서 상태 변화로 리랜더링 > 그 안에 있는 createElement도 재호출 > 결과적으로 자녀 앨리먼트도 리랜더링 이 순서입니다. 제가 영상 초반에 state하고 props에 의존해서 리랜더링 한다는 것의 주어는 각 컴포넌트가 아닙니다. 자녀 엘리먼트를 엘리먼트가 아니라 함수라고 생각하시면 쉬울거 같습니다.
useCallback을 써서 눈에 보이는 변화가 안생기는 경우가 많다보니 안쓰는게 많죠. 반드시 자주 쓰는 setState에 useCallback을 사용하는건 아닙니다 ㅎㅎ 많은 주니어 분들은 당연히 useMemo, React.memo를 안쓰고 하는 경우가 많고, 개발하다보면 잊고 그냥 개발하는 경우도 많습니다. 보통 이런걸 꼭 쓰는 경우는 리랜더링 과정에서 API 반복 요청이 발생하거나 리랜더링으로 인한 UX상 문제가 생기거나 메모리 사용량이 과도하게 늘어나 작동상 불편함이 있거나 하는 등 문제가 생겨야 적용하는 경우가 많은듯 합니다.
ㄹㅇ 도움됐다
너무 좋습니다 오늘도 좋은 영상 감사합니다
정말 좋은 설명이네요. 감사합니다~
리엑트를 처음 시작해서 개념을 잡기 힘들었는데
큰 도움이 됬습니다.
감사합니다.
좋은 영상 감사합니다 😀
많이배우고갑ㄴ다 선배님❤
왜 사용하는지는 잘 설명해주셔서 이해 했는데 활용하기는 어렵네요 감을 잡게 된 것 같습니다. 감사합니다.
늘 감사히 보고 있습니다!
항상 봐주셔서 감사합니다! ❤️
너무 알찼습니다 감사합니다:)
도움이 되셨다니 다행입니다. 감사합니다.
감사합니다
항상 감사합니다!
저도 항상 감사합니다 🙏
useMemo도 원본 데이터가 복잡한 경우 평탄화 해도 발생하는 문제가 많습니다.
라이브 데이터기준으로요
현명한 개발자라면 평탄화가 하기 힘든 데이터를 억지로 useMemo로 넣기보다는 메모이제이션이 효과를 발휘하는 상황에만 사용해야겠죠?
@josehp_han 메모 넣으면 만능인것 처럼 설명하는게 많아서 기계적으로 댓 달았네요.
메모보단 컴포넌트 구조, 상태관리 시 추가,삭제가 아닌 재할당 행위 줄이기 key값 유니크하게 관리하기 등 리렌더 줄이는대 더 도움되는것들이 많은대 그거 설명하는 사람 본적이 없어요.
강의 영상을 찍을 때 어려움이 이런 부분입니다. 모든 경우도 모든 상황도 스펙에서 당연히 고려해야하는 상황 중 하나라도 빠져면 이런 댓글이 달리고, 그러면 저는 마치 만능으로 이걸 설명한 사람이 되는거죠.
영상 처음부터 보시면 아시겠지만 이런 식으로 줄일 수 있다고, 당연하게도 라이브 데이터 말씀하셨는데 라이브가 실시간 반영되어 렌더링 되는 요소라면 애초에 메모이제이션이 왜 필요할까요. 저는 제 영상에서 빠진 내용보다 댓글에서 지적을 하실 때 영상 찍는 사람 입장도 생각해보셨으면 하네요.
@@josehp_han 뭔가 개발영상 찍는분들의 고민 같은거군요.
저가 말을 공격적으로 해서 감정상하셨음 사과드립니다.
알고리즘에 하도 비슷한게 떠서 추천금지 눌러도 뜨길래 저렇게 단거지
영상 의도 자체는 잘 전달되었습니다.
이해해주셔서 감사합니다. 또한 영상 관심있게 시청해주신 것도 감사합니다.
리액트 랜더링 과정 1. render, 2. commit에 대한 컨텐츠도 올려주시면 감사하겠습니다.
state를 변경할 때 가끔 왜 바로 화면에 적용이 안되고 한텀 뒤에 랜더링되서 보이지? 하는 경우가 있는데 아마도
2. commit이라고 말씀하신 부분을 이해하지 못해서 그렇게 느끼는거라고 의심이 드네요....
영상 스케줄에 고려해보겠습니다. 참고로 제 개발 관련 영상은 이제 모두 개발자 전용 채널에서 올라가니 www.youtube.com/@Codemasterhan 여기에 나중에 기회되면 올려볼께요~
내용이 생각보다 길지 않아 바로 제작해봤습니다. 오늘 밤 10시에 영상 올라갈겁니다~ 주제 추천 감사합니다.
@@josehp_han 오 감사합니다. 구독 좋아요 눌렀습니다.
위 예시에서 useMemo자리에 useRef 로 적용할때 비교도 추가 설명해주실 수 있을까요?
특별히 따로 뺄만큼 분량이 나올것 같지는 않은데 ㅎㅎ 제 소스코드에서 변경해서 직접 해보시면 좋을듯 합니다. 만약 그런데도 이해가 안되거나 동작이 납득이 안되시멐 댓글 남겨주세요~
좋은개념 너무 감사합니다. Api 호출 여러번되는거같아서 인지는했지만 개발속도에만 집중하느라 신경을 못썼는데 좋은거 배워갑니다. 혹시 useCallback만 사용하면되는 경우는 어떤경우인가요? Render phase에 영향안끼치는 경우라 생각들어 함수가 props나 state가 아니면 될것같은데 그럴때라면 굳이 useCallback자체를 안써도될것같다는 생각이드는데 제가생각못한 다른경우도있나요? 아니면 제 사고과정에 문제가있나요?
useCallback은 컴포넌트 내에서 함수가 선언된 것에 대해서 메모이제이션하는 기능이기 때문에 함수가 커서 재선언을 방지하는게 효율이 좋다면 사용하면 됩니다.
가령 부모 컴포넌트에 속한 함수가 있을 때 부모 컴포넌트에서 유발된 리랜더링이 거의 없는 상태라면 굳이 useCallback으로 묶을 필요가 없습니다. 도리어 메모리 낭비가 될 수 있겠죠. 반면 함수가 작을지라도 부모 컴포넌트 내에서 다른 이유로 리랜더링이 발생하고 있고, 이에 따라 함수도 재선언되어 이를 참조하는 컴포넌트들이 많은 상태라면 useCallback을 사용하는게 좋습니다.
@@josehp_han 답변너무 감사드립니다❤️
@@josehp_han
재선언을 하는 비용만 줄이는건지 궁금합니다.
메모리 비용은 결국에 렌더링되며 생성해도 1칸이고 메모이제이션해도 1칸 아닌가요?
@@공민제-h6k 단순히 1이다 2다 말할 수 는 없을 것 같습니다. 정확히 얼마의 메모리가 매번 사용되는지는 리액트 소스코드를 뜯어 분석하는 수준이 되어야 할 것 같고, useCallback의 로직이 단순히 메모이제이션을 해두진 않을 겁니다.
비슷한 예로 useState도 단순한 게터, 세터로 구성된 것 같지만 그 안에 로직은 훨씬 복잡하기 때문이죠.
또한 감싸려는 함수마다 비용도 각자 다를 것입니다. 단순 렌더링 과정에서 재선언이 이뤄졌다면 그 과정에서 즉각적으로 가비지 컬렉팅이 됐는지 안됐는지 확인하기 전까지는 모르죠.
이러한 이유에서 useCallback의 성능을 측정할 때는 반복 횟수를 극단적으로 높여서 비교를 하게 되고, 안에 들어간 함수에 따라서도 결과의 차이는 존재합니다.
그러므로 단순히 메모리 1칸 정도로 계산할 수는 없다고 봅니다.
의존성에 []를 넣은경우처럼 컴포넌트 내부 변수를 사용하지 않는 케이스에는 외부에 선언해주는게 보다 좋은 방법이지 않나 생각이 드는데 맞는 생각일까요?
질문이 이해가 안되네요
@@josehp_han 03:57 에서 "컴포넌트 함수(App 함수) 내부에 선언된 함수나 값은 컴포넌트 함수가 다시 실행(리랜더링) 될 때마다 새롭게 선언되기에 자식도 리랜더링이 발생하고 이를 막기 위해 useCallback을 사용한다." 라는 설명에서
재선언을 막는 또 다른 방법으로 App() 컴포넌트 함수의 외부에 변수 또는 함수를 선언하여 변수(함수)가 새롭게 선언되지 않도록 하는것이 더 좋은 방법이 아닐까 생각이 들어 질문드렸습니다.
(단, 함수 내부의 변수에 접근할수 없으므로 함수 내부 변수를 의존하지 않는 케이스로 한정했습니다.)
자동완성이 되게하려면 어떤 걸 깔아야하나요?
Copilot 사용하시면 됩니다~
안녕하세요 ! 혹시 바쁘시겠지만 vscode theme에 사용하신 테마 정보 알 수있을까해서 글남겨봅니다!
LaserWave입니다~
안녕하세요, 리렌더링이 발생할 조건에 부모 컴포넌트 리렌더링도 있지 않나요?
네 영상에서처럼 부모컴포넌트에 해당하는 App.js의 리랜더링이 하위 컴포넌트에 리랜더링을 유발한 모습입니다. 정확히 표현하자면 리랜더링 조건이 state, props 뿐 아니라 부모 컴포넌트의 리랜더링이기도 말할 수 있겠지만, 부모 컴포넌트 입장에서 보면 리랜더링을 하면서 자녀 엘리먼트라는 엘리먼트 생성함수를 다시 선언하고 호출한 격입니다.
그렇기 때문에 자녀 엘리먼트 기준에서는 3가지 기준이 될 것이고, 리액트라는 시스템의 기준에서는 최상위 엘리먼트부터 state, props의 변화에 따라 리랜더링이 발생하며, 그 과정에서 하위 컴포넌트는 리랜더링으로 볼 것이냐 랜더링으로 볼것이냐의 차이가 될겁니다.
사실 크게 의미없는 분류긴한데 자세히 설명드렸습니다.
저는 왜 rendering last item: 99 콘솔이 찍히고 updated 콘솔이 한번만 찍힐까요?? 영상에서는 2번찍히는데..
Strict mode 꺼두시면 한 번 나오는게 맞습니다
@@josehp_han Strict mode를 켜도 updated 콘솔만 이상하게 한번찍히네요..
이것보다 다른 중요한 궁금점이 있습니다.
ManyRenderingComponent가 재랜더링 되는 이유는 onClick 함수때문이 아니라 App.js에 있는 setState(1) 때문에 리랜더링 되는거 아닌가요?
onClick() 함수를 메모함으로 인해서 리랜더링이 방지되는 구조라면 onClick 함수를 제거하고 props가 존재하지 않으면 리랜더링이 되지 않아야 한다고 생각합니다.
입문자라 질문이 이상할 수 있는데 너무 이해가 안되서 질문 드립니다 ㅠㅠ
Use strict가 아니라 react strict mode가 있으면 2번 발생합니다. 똑같이 구현하시려면 cra로 만든다음 제 코드 똑같이 구현해보시면 어떤 의미인지 아실 수 있을 것 같아요!
두번째로 onClick은 커밋 페이즈를 줄여준거고 부모 엘리먼트의 상태 변경으로 인해서 불필요하게 자녀 앨리먼트도 리랜더링이 되는거라 useCallback하고 React.memo로 감싸서 리랜더링을 방지해주는 겁니다 😅
그래서 영상에서 onClick을 콜백으로 감싸줘도 여전히 리랜더링 되는게 확인되실겁니다!
Props를 제거했는데도 리랜더링이 생기는 이유를 더 설명드리자면 자녀 엘리먼트를 고정된 HTML이라고 보시면 안됩니다. 영상 중반에 나온것처럼 리액트 컴포넌트 함수는 React.createElement를 최종적으로 리턴하는 함수라보시면 됩니다.
부모 엘리먼트에서 상태 변화로 리랜더링
> 그 안에 있는 createElement도 재호출
> 결과적으로 자녀 앨리먼트도 리랜더링
이 순서입니다.
제가 영상 초반에 state하고 props에 의존해서 리랜더링 한다는 것의 주어는 각 컴포넌트가 아닙니다. 자녀 엘리먼트를 엘리먼트가 아니라 함수라고 생각하시면 쉬울거 같습니다.
한컴포넌트 안에서 자주 쓰는 setstate가 들어간 함수에다가 usecallback 다는게 맞는거죠?? 아직 주니어고 5개월 일하면서 usecallback말고는 useMemo,React.memo의 필요성을 못느끼고있는데 제가 비정상인가요😂😂??
useCallback을 써서 눈에 보이는 변화가 안생기는 경우가 많다보니 안쓰는게 많죠. 반드시 자주 쓰는 setState에 useCallback을 사용하는건 아닙니다 ㅎㅎ 많은 주니어 분들은 당연히 useMemo, React.memo를 안쓰고 하는 경우가 많고, 개발하다보면 잊고 그냥 개발하는 경우도 많습니다. 보통 이런걸 꼭 쓰는 경우는 리랜더링 과정에서 API 반복 요청이 발생하거나 리랜더링으로 인한 UX상 문제가 생기거나 메모리 사용량이 과도하게 늘어나 작동상 불편함이 있거나 하는 등 문제가 생겨야 적용하는 경우가 많은듯 합니다.