esoby 님의 상세페이지 ＞ [4팀 김소희] Chapter 1-3. React, Beyond the Basics

[4팀 김소희] Chapter 1-3. React, Beyond the Basics

by esoby2025. 7. 22.

과제 체크포인트

배포 링크

esoby.github.io/front_6th_chapter1-3/

기본과제

equalities

  • shallowEquals 구현 완료
  • deepEquals 구현 완료

hooks

  • useRef 구현 완료
  • useMemo 구현 완료
  • useCallback 구현 완료
  • useDeepMemo 구현 완료
  • useShallowState 구현 완료
  • useAutoCallback 구현 완료

High Order Components

  • memo 구현 완료
  • deepMemo 구현 완료

심화 과제

hooks

  • createObserver를 useSyncExternalStore에 사용하기 적합한 코드로 개선
  • useShallowSelector 구현
  • useStore 구현
  • useRouter 구현
  • useStorage 구현

context

  • ToastContext, ModalContext 개선

과제 셀프회고

기술적 성장

  1. useSyncExternalStore 훅의 존재를 알게 되다 !
  • 렌더링이 일시정지 될 수도 있는(!) Concurrent Features 환경에서 외부 스토어에서 관리되는 상태와 컴포넌트 간의 Tearing 현상을 방지하고 안전하게 동기화하기 위해 사용되는 훅이다.
  • 심화 과제 들어가기 전에 수업 교재도 읽고 공식 문서도 찾아보고 팀장님의 블로그 글도 정독하고 ~ 개념 이해에 시간이 많이 들었던 것 같다 . . * 상태 관리 라이브러리는 자주 사용했는데 내부적으로 요런 게 사용되고 있는지 처음 알았다!
  1. 참조 동일성에 대해 다시 생각해보다 !
  • 코딩을 C언어로 시작해서 너무 다행이에요. < ?
  • shallowEquals를 직접 구현하면서, 눈에 보이는 데이터의 내용 변동이 아닌 메모리 상의 참조 값 변경이 렌더링에 영향을 미친다는 것을 다시 한 번 머리에 집어넣게 되었습니다.
  1. 최적화 훅들의 역할을 명확히 하다 !
  • 렌더링 최적화를 위한 use~ 친구들에 대해 이론적으로만 알고 있었다는 사실을 깨달았습니다. 직접 함수나 컨텍스트 하나하나 렌더링과의 연결고리를 생각해보고 최적화 도구들을 적절하게 넣어보는 .. 경험 덕분에 좀 더 각각의 역할이 명확하게 정리된 것 같습니다.

자랑하고 싶은 코드

  1. useShallowSelector와 절교 위기에 봉착하다
  • 자랑은 아니고 .. 저 얘 때문에 너무 힘들었어요. 제가 너무너무 어렵고 복잡하게 생각해서 혼자 둘레길 한바퀴 돌고 돌아온 것 같ㅅ브니다..
// ...
const memoizedSelector = useCallback((state: T): S => {
// ...
  return selectedRef.current as S;
}, []); 

return memoizedSelector;
  • 그니까 저는 useShallowSelector 훅의 반환 값도 useCallback으로 참조 안정화를 시켜 리턴해야 한다고 생각했거든요. . . 저렇게 복잡하게 운을 떼니까 아주 한참 헤맸고 ai랑도 싸웠고요 .. 익명 함수로 리턴하니까 useStore 테스트 코드 렌더링 횟수가 일치하게 되더라고요 엉엉어ㅡㅇ 심화 과제 때는 개념이 모호했어서 그런지 자꾸 테스트 코드의 기대와 멀어지는 일이 많았읍니다.

개선이 필요하다고 생각하는 코드

  1. Object.is 적용
  2. Object.prototype.hasOwnProperty.call 적용

학습 효과 분석

  1. 훅에 중독되다 .. !
  • 실 과제 작업 기간인 약 4일 간, 회사 업무에서 커스텀 훅을 6개 정도 생성해내었습니다. 관심사 분리가 안 된다거나 한 컴포넌트 내 스크립트가 너무 무겁다거나 다시 보니 한 눈에 안 들어오는 코드라거나 .. 다 냅다 빼고 있어요! 리팩토링 할 때도 기능 구현 관점에서만 생각하지 않고 렌더링 트리거에 대해서도 점검하는 습관이 생겼습니다 아이 조아

과제 피드백

  • 자바스크립트 (강제) 딥 다이브! 너무 의미있는 시간이었던 것 같아요 이번 챕터 과제 덕분에 시야가 많이 넓어진 것 같습니다. 아쉬운 점이 많아서 종강하고 다시 들여다보고 싶어요!

학습 갈무리

리액트의 렌더링이 어떻게 이루어지는지 정리해주세요.

  • 리액트의 렌더링은 상태 변경, 프롭스 변경, 컨텍스트 변경, 부모 컴포넌트 리렌더링 등으로 유발됩니다. 트리거가 활성화되면 리액트는 해당 컴포넌트부터 모든 자식 컴포넌트 함수를 호출합니다! 리액트는 함수로부터 반환된 JSX를 가상 dom 객체 형태로 변환하고, 이전 렌더링 타이밍의 가상 dom 트리와 diff 알고리즘을 통해 변동 사항을 확인합니다. 그리고 실제 DOM에 변경 사항을 최소 단위로 적용합니다.
  • 불필요한 렌더링을 최대한 줄이는 것이 렌더링 최적화의 방향입니다. 메모리를 적절하게 사용해서 렌더링을 유발하지 않는 값을 관리하거나, 변경 여부를 판단해 렌더링을 트리거합니다.
    • useState, useReducer, useRef, useMemo, useCallback

메모이제이션에 대한 나의 생각을 적어주세요.

  • 메모! 해두는 것! 입니다. 반복적으로 불필요한 연산을 하거나 렌더링 트리거가 되는 것을 방지하기 위해 이전 결과값을 저장해두고 재사용하는 최적화 기법입니다. 연산 시간을 절약해 애플리케이션 성능 향상을 기대할 수 있지만, 메모이제이션 자체의 비용과 메모리 사용량 때문에 오버헤드가 발생하지 않도록 메모이제이션 대상을 잘! 고려해야 합니다.

컨텍스트와 상태관리에 대한 나의 생각을 적어주세요.

  • 여러 컴포넌트에서 필요로 하는 데이터를 효율적으로 공유하기 위해 필요합니다. 데이터를 공유하고자 데이터를 계속계속 부모로 끌어올리는 것도 불필요한 렌더링을 유발하고, 프롭스 드릴링이 생겨 코드 유지 보수가 어려워질 수 있습니다! 하지만 스토어가 너무 무거운 것도 .. 데이터 흐름 파악이 어려우지기 때문에 적당히 ~!

리뷰 받고 싶은 내용

과제 피드백

안녕하세요 소희님! 3주차 과제 잘 진행해주셨네요 ㅎㅎ 고생하셨습니다!!

자랑은 아니고 .. 저 얘 때문에 너무 힘들었어요. 제가 너무너무 어렵고 복잡하게 생각해서 혼자 둘레길 한바퀴 돌고 돌아온 것 같ㅅ브니다..

ㅋㅋㅋㅋㅋ 제가 의도한 학습과정(?)을 제대로 경험해주셨네요. 뿌듯(?) 합니다 ㅎㅎ

실 과제 작업 기간인 약 4일 간, 회사 업무에서 커스텀 훅을 6개 정도 생성해내었습니다. 관심사 분리가 안 된다거나 한 컴포넌트 내 스크립트가 너무 무겁다거나 다시 보니 한 눈에 안 들어오는 코드라거나 .. 다 냅다 빼고 있어요! 리팩토링 할 때도 기능 구현 관점에서만 생각하지 않고 렌더링 트리거에 대해서도 점검하는 습관이 생겼습니다 아이 조아

오옹! 너무 잘 해주고 있네요!! 저희 팀은 custom hook이 거의... 1000개 정도 되는 것 같아요 ㅋㅋ 저는 컴포넌트는 오직 "값"에 관심이 있고, 값을 만들어내는 과정은 훅으로 분리해야 한다고 생각해요! 이러면 테스트 하기도 수월해지고!?

과제 자체보다 소희님께서 실무적으로 계속 응용하고 있다는 점이 인상깊네요 ㅎㅎ 고생하셨습니다!! 앞으로도 화이팅입니다!!