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

[esoby]

과제 체크포인트

배포 링크

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 현상을 방지하고 안전하게 동기화하기 위해 사용되는 훅이다.
• 심화 과제 들어가기 전에 수업 교재도 읽고 공식 문서도 찾아보고 팀장님의 블로그 글도 정독하고 ~ 개념 이해에 시간이 많이 들었던 것 같다 . . * 상태 관리 라이브러리는 자주 사용했는데 내부적으로 요런 게 사용되고 있는지 처음 알았다!

2. 참조 동일성에 대해 다시 생각해보다 !

• 코딩을 C언어로 시작해서 너무 다행이에요. < ?
• shallowEquals를 직접 구현하면서, 눈에 보이는 데이터의 내용 변동이 아닌 메모리 상의 참조 값 변경이 렌더링에 영향을 미친다는 것을 다시 한 번 머리에 집어넣게 되었습니다.

3. 최적화 훅들의 역할을 명확히 하다 !

• 렌더링 최적화를 위한 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

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

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

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

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

리뷰 받고 싶은 내용

[eveneul]

우리 소희 님 파이팅~~!!

[BangDori]

소희님 고생하셨어요!! 3주차 과제 수행하시면서 Hook 딥 다이브 하시고 또 이걸 회사 업무에도 바로 적용하신다니 정말 짱 멋있으십니다..

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

요 부분에서 이야기를 나눠보고 싶은 부분이 있는데요! 저도 처음에는 관심사를 크게 Logic과 View의 관점으로만 바라보고 냅다 다 빼서 분리를 했었는데, 이렇게 하니 리팩토링을 하려고 다시 돌아왔을 때 코드를 한 눈에 이해하기 힘들다거나 리팩토링이 어려운 상황이 종종 생기더라구요. 그래서 혹시 소희님은 이런 상황에 어떻게 대응하시는지 아니면 처음에 관심사를 분리하는 시점부터 관심사를 잘개 쪼개시는 편인지 궁금해요. (혹시 나만의 꿀팁이 있다면... 공유해줘요 🥹)

[esoby]

요 부분에서 이야기를 나눠보고 싶은 부분이 있는데요! 저도 처음에는 관심사를 크게 Logic과 View의 관점으로만 바라보고 냅다 다 빼서 분리를 했었는데, 이렇게 하니 리팩토링을 하려고 다시 돌아왔을 때 코드를 한 눈에 이해하기 힘들다거나 리팩토링이 어려운 상황이 종종 생기더라구요. 그래서 혹시 소희님은 이런 상황에 어떻게 대응하시는지 아니면 처음에 관심사를 분리하는 시점부터 관심사를 잘개 쪼개시는 편인지 궁금해요. (혹시 나만의 꿀팁이 있다면... 공유해줘요 🥹)

빵도릐님 피알 놀러와주셔서 감사해요 ㅎ.ㅎ .. 붂그럽네요.

저는 리팩토링을 결심하는 계기가 오히려 그 부분인 것 같아요! 다른 작업을 하다가 다시 돌아갔을 때, 한 눈에 코드가 들어오지 않고 기능 추가나 리팩토링 등 추가 작업이 버겁게 느껴지는 지점이요! 주로 같은 데이터를 공유하는 로직끼리 동일한 관심사로 간주하고 분리하는 편인 것 같아요. 그래서 컴포넌트의 스크립트에는 렌더링에 사용할 데이터와, 이벤트 핸들러의 액션만 남겨서! 이 친구가 무슨 역할을 하는지! 분명하도록 만들고자 하는 거 같아요,,! 저도 아직 부족하기도 하고 항상 좋은 코드에 대한 고민이 많은데,,,,,,,,! 클린코드 챕터 같이 으쌰으쌰해서 초고수가 되어봅씨다

[BangDori]

저도 평소에 같은 데이터를 공유하는 로직끼리 묶는 것을 원칙으로 분리하려고 시도했었어요. 그런데 리팩토링이나 설계 과정에서 같은 데이터를 기준으로 잘 나눴다고 생각했음에도 코드가 오히려 복잡해지는 경우를 종종 겪게 되더라고요....

이게 생각을해보니 내가 분리하려고 하는 이 로직이 정확히 어떤 로직이다!라는 생각 없이 단순히 폴더 구조나 디자인 패턴에 의존해서 추상적으로 나누려고 하다 보니 발생하는 것 같더라구요. 그래서 겉으로는 나뉘어 보이지만, 실제 동작 흐름이나 데이터 관점에서는 오히려 더 어색해지는 경우도 있었어요. (FSD 아키텍처를 도입했을 때 처음에는 신세계였는데, 규모가 커질수록 상당히 복잡해지더라구요...)

그래서 조금은 다른 방법으로 시도해보려고 찾아보고 있던 중 클린 코드 책에서 한 문장이 눈에 띄었어요.

"지금까지 자신이 읽은 책 중 진짜로 좋았던 책을 떠올려보라. 책을 읽는 동안 단어가 사라지고 이미지가 떠오르지 않았는가? 마치 한 편의 영화를 보듯이 말이다."

Clean Code 책 중 일부

사실 이 문장을 2~3번 반복해서 읽었는데, 문장을 이해하려고 노력하다 보니 한 가지 생각을 해본게 코드도 소설을 읽듯이 읽을 수 있으면 얼마나 좋을까 하고요. 그래서 요즘은 무의식적으로 명확한 의도없이 추상적으로 기능을 분리하던 습관을 버리고, 글을 쓰듯 코드를 작성하려고 노력하고 있어요.

요즘 짬날 때 읽고 있는 『바바라 민토의 논리의 기술』이라는 책에서 나온 피라미드 모델도 큰 영감을 주었어요. 논리적인 흐름을 결론 -> 근거 -> 세부 설명 구조로 전개하는 방식인데요, 사실 말보다는 사진이 더 좋으니까..

이런식으로 구성이 되요! React 트리 구조 같지않나요? ㅎ 그래서 요즘은 코딩을 할 때, 위 피라미드 모델을 도입해서 코딩을 해보려고 노력 중인데 생각보다 괜찮은 거 같아요.

글을 다 쓰고보니까 좀 TMI인 거 같기도 하네요 ㅋㅋ

참고

• 논리의 기술 – 좋은 보고서 작성법