현재 노트: KR-410.20 c
상위 분류: KR-410.20 독서

#React #독서

https://www.yes24.com/Product/Goods/124899726
리액트 훅을 활용한 마이크로 상태 관리 리액트 상태 관리의 기본 개념부터 동작 원리와 문제 해결, 렌더링 최적화 기법까지
다이시 카토 저/이선협, 김지은 역

책을 읽게 된 이유

해당 책은 다른 분의 추천으로 알게된 책입니다. React의 상태가 중요하다고 하는데 좀 더 깊게 알아보고 싶다는 이유로 이 책을 읽기로 하였습니다. 이 책에서는 "이렇게 까지 상태관리를?" 이라는 생각이 들게 할 정도로 상태 관리에 대한 깊은 고민과 해결 과정이 담겨있었습니다.

글을 작성하는 이유

책을 제대로 읽었는지 스스로 점검해보기 위하여 책을 읽기전 모든 목차에 대한 내용을 간단하게 작성하고, 책을 읽은 후 한 번 더 작성해 보는 방식으로 글을 쓰게 됐습니다.

책을 읽고난 뒤

• Hooks에 대한 깊이가 증가함 특히 useState, useEffect
• React의 순수 함수를 지향한다는 말의 의미를 조금 이해함(원시값과 객체의 렌더링 차이) immutable
• 지역 상태를 지향하지만 필요한 경우 전역 상태를 사용하며 이에 따라 prop drilling을 방지하며 리렌더링을 최적화 하기 위한 방법에 대해 이야기 할 수 있다.
• useContext를 통해 전역 상태변수를 Provider 계층을 통해 관리함 을
• 컴포넌트가 리렌더링 되는 경우 2가지인 부모나 본인의 props변경 또는 컨텍스트 값의 변화가 생길 떄를 이해할 수 있다.
• 전체적으로 contextAPI와 모듈 상태를 통해 전역 상태를 관리 하기 위한 시도, 둘의 장단점 그리고 이 둘의 장점을 고려한 라이브러리들의 시도를 이해할 수 있게된다다
• zustand, zotai 라이브러리 사용이유와 차이점 설명 할 수 있게 된다

아래부터는 책의 모든 목차에 대하여 읽기 전(before) 읽은 후(after)의 감상을 짧게 요약합니다
사용된 목차 출처: https://www.yes24.com/Product/Goods/124899726
사용된 코드 출처: https://github.com/wikibook/msmrh

• [01장: 리액트 훅을 이용한 마이크로 상태 관리]

  • 마이크로 상태 관리 이해하기

    before: 잘 모르겠음.
    after: 다양한 개발 요구 상황에 맞춰 가볍게 상태관리를 하는 것. React에서 상태를 관리하는 것은 필수이며 어려움. 이에 대한 이해가 필요

  • 리액트 훅 사용하기

    before: 리액트 컴포넌트 동작을 위한 단위 동작 함수
    after: 추가로 React의 State와 life cycle 관리를 위한

  • 데이터 불러오기를 위한 서스펜스와 동시성 렌더링

    before: 잘 모르겠음.
    after: 서스펜스는 데이터 로딩 시 대기 처리, 동시성 렌더링은 대기 중인 컴포넌트를 건너뛰며 준비된 부분부터 렌더링하는 방법 (동시에 여러 개 렌더링하는 것은 아님)

  • 전역 상태 탐구하기

    before: 상태 관리에 있어서 컴포넌트가 위치에 상관없이 접근할 수 있는 상태
    after: React는 기본적으로 로컬 상태를 사용하며, 전역 상태는 필요할 때만 사용 (컴포넌트의 범위가 좁을수록 명확해져서 선호됨)

  • useState 사용하기

    before: 상태관리에 사용되는 훅으로, 일반적으로 state와 setState의 한 쌍으로 업데이트
    after: (동일)

  • 값으로 상태 갱신하기

    before: 예를 들어 count와 같은 값을 업데이트하는?
    after: 원시값 업데이트, 객체 업데이트 시 얕은 복사 때문에 내부 프로퍼티 변경은 리렌더링 안됨; 새 객체 생성 시 리렌더링됨

  • 함수로 상태 갱신하기

    before: setState에 값을 직접 넣지 않고, 함수를 통해 복잡한 상태 업데이트 관리
    after: setState에서 prev와 같은 값을 통해 업데이트하기

  • 지연 초기화

    before: 잘 모르겠음.
    after: 성능 최적화를 위해 비용이 큰 초기값을 함수 형태로 전달하여 최초 렌더링 시에만 호출

  • useReducer 사용하기

    before: 잘 모르겠음.
    after: useState보다 복잡한 상태 관리를 위한 훅

  • 기본 사용법 (useReducer)

    before: 잘 모르겠음.
    after: reducer(prev, action) 형태이며, useReducer(reducer, initialValue) 사용 추가 검색결과 렌더링 최적화를 위해 init함수 형태도 가능

  • 베일아웃

    before: 잘 모르겠음.
    after: 리렌더링되지 않는 조건; 최적화를 위해 일부러 이런 구조로 만들 수 있음.일부로 같은 값을 return 함으로서 리렌더링이 일어나지 않게함

  • 원시 값

    before: 잘 모르겠음.
    after: 객체가 아닌 단순 값

  • 지연 초기화(init)

    before: 잘 모르겠음.
    after: useState와 useReducer에서 계산 비용이 큰 함수를 초기 렌더링 시에만 호출하도록 함수 형태로 전달

  • useState와 useReducer의 유사점과 차이점

    before: 잘 모르겠음.
    after: 둘은 거의 비슷하지만, 외부 접근 방식에 차이가 있음

  • useReducer를 이용한 useState 구현

    before: 잘 모르겠음.
    after:

  • useState를 이용한 useReducer 구현

    before: 잘 모르겠음.
    after:

  • 초기화 함수 사용하기

    before: 잘 모르겠음.
    after: useReducer에서는 외부에서 사용 가능, useState에서는 불가 (거의 사용되지 않음)

  • 인라인 리듀서 사용하기

    before: 잘 모르겠음.
    after: useReducer에서 외부 사용 가능, useState에서는 불가 (거의 사용되지 않음)

[02장: 지역 상태와 전역 상태 사용하기]

• 언제 지역 상태를 사용할까?

  before: 다른 컴포넌트에서 접근하지 않는 상태면 지역 상태가 적절.
  after: 오히려 대부분의 경우 기본적으로 지역 상태를 지향하는 것이 맞음. 컴포너트 내에서만 처리하기. 하지만 현실적으로 다른 컴포넌트와 공유되는 값이나 외부로부터 가져와야만 하는 값때문에 쉽지 않음

• 함수와 인수

  before: 함수는 템플릿, 인수는 실제 동작 인스턴스.
  after: 함수를 동작시키기위한 파라미터가 인수

• 리액트 컴포넌트와 props

  before: 컴포넌트는 논리 단위, props는 상위에서 하위로 전달되는 파라미터.
  after: (동일).

• 지역 상태에 대한 useState 이해하기

  before: 잘 모르겠음.
  after: 지역 상태는 컴포넌트 내부에 격리되어 독립적으로 관리할 수 있음.

• 지역 상태의 한계

  before: 잘 모르겠음.
  after: 외부에서 상태 변경이 필요한 경우, 지역 상태는 한계가 있음.

• 지역 상태를 효과적으로 사용하는 방법

  before: 잘 모르겠음.
  after: Lifting을 통해 중복을 제거하고 부모로 상태를 끌어올리며 리렌더링 최소화

• 상태 끌어올리기 (Lifting State Up)

  before: 잘 모르겠음.
  after: 공유 상태를 부모 컴포넌트로 끌어올려 하위 컴포넌트에 전달하는 방식.

• 내용 끌어올리기 (Lifting Content Up)

  before: 책읽기 전: 잘 모르겠음.
  after: 하위 컴포넌트의 불필요한 리렌더링을 방지하기 위해, 영향 받지 않는 부분을 상위로 끌어올림.

• 전역 상태 사용하기

  before: (설명이 없음)
  after: 여러 컴포넌트에 걸쳐 공유되는 상태로, props로 전달하기 어려운 경우 사용.

• 전역 상태란?

  before: 잘 모르겠음.
  after: 하나의 값 또는 여러 값을 공유하는 상태로, 컴포넌트 경계를 넘어 사용됨.

• 언제 전역 상태를 사용할까?

  before: 잘 모르겠음.
  after: props 전달이 번거롭거나 여러 컴포넌트 간에 공유되어야 할 때 사용.

• 정리

  before: 잘 모르겠음.
  after: 지역 상태는 기본적으로 사용하고, 필요에 따라 lifting을 통해 전역 상태로 확장함.

• [03장: 리액트 컨텍스트를 이용한 컴포넌트 상태 공유]

  • useState와 useContext 탐구하기

    before: 책읽기 전 설명 없음
    after: 둘 다 사용 하여 지역 및 전역 변수로서 활용

  • useContext 없이 useState 사용하기

    before: useContext 이해 부족
    after: 각 컴포넌트별로 별도의 상태 저장

  • 정적 값을 이용해 useContext 사용하기

    before: useContext 이해 부족
    after: createContext를 통해 글로벌 값처럼 전달. state lifting

  • useContext와 함께 useState 사용하기

    before: useContext 이해 부족
    after: state와 setState 튜플을 context에 전달하여 글로벌 관리

  • 컨텍스트 이해하기

    before: 설명 없음
    after: 공급자의 값 갱신 시 하위 소비자 모두 업데이트되므로 최적화 필요

  • 컨텍스트 전파의 작동 방식

    before: 설명 없음
    after: Provider 값 갱신 시 모든 소비자가 업데이트되며, 이를 방지하려면 lifting 또는 memo 사용

  • 컨텍스트에 객체를 사용할 때의 한계점

    before: 설명 없음
    after: 객체는 불필요한 리렌더링을 유발할 수 있음

  • 전역 상태를 위한 컨텍스트 만들기

    before: 설명 없음
    after: 작은 상태 조각으로 관리하거나 useReducer 사용 고려

  • 작은 상태 조각 만들기

    before: 설명 없음
    after: 하나의 객체 대신 개별 상태로 관리

  • useReducer로 하나의 상태를 만들고 여러 컨텍스트로 전파하기

    before: 설명 없음
    after: 잘 이해 안가는데 뉘앙스는 useState때처럼 dispatch에 Context를 개별로 배치한다. 이러면 Context값을 여러개로 쪼개서 불필요한 리렌더링 방지

  • 컨텍스트 사용을 위한 모범 사례

    before: 설명 없음
    after: (잘 이해 안감)

  • 사용자 정의 훅과 공급자 컴포넌트 만들기

    before: 설명 없음
    after: (잘 이해 안감)

  • 사용자 정의 훅이 있는 팩토리 패턴

    before: 설명 없음
    after: (잘 이해 안감)

  • reduceRight를 이용한 공급자 중첩 방지

    before: 설명 없음
    after: (잘 이해 안감)

  • 정리

    before: 설명 없음
    after: 글로벌 state 관리를 위해 context를 활용하며, useState를 객체 형태로 전달하는 패턴 사용.
    중요한 것은 Context를 Provider 별로 여러개 쪼개서 필요한 컨텍스트만 반영하게 만들어서 불필요한 렌더링을 줄이기

• [04장: 구독을 이용한 모듈 상태 공유]

  • 모듈 상태 살펴보기

    before: 잘 모르겠음.
    after: 전역변수와 같은느낌인데 모듈블럭이나 파일 수준으로 정의된 state

  • 리액트에서 전역 상태를 다루기 위한 모듈 상태 사용법

    before: 잘 모르겠음.
    after: export키워드로 다른 파일에서 import

  • 기초적인 구독 추가하기

    before: 잘 모르겠음.
    after: subscribe라는 함수로 값이 갱신되면 콜백함수를 이용한다는 느낌

  • 선택자와 useSubscription 사용하기

    before: 잘 모르겠음.
    after: 잘모르겠음

  • 정리

    before: 없음
    after: 특정값이 변경되면 해당 값을 구독하는 상태에 업데이트 콜백을 전달하는 모듈 state. 여기서 store나 subscription등의 용어가 사용됨. 나중에 zustand에서 사용하는 용어의 어원인듯

• [05장: 리액트 컨텍스트와 구독을 이용한 컴포넌트 상태 공유]

  • 모듈 상태의 한계

    before: 설명 없음
    after: 모듈은 특정 값 추적 시 리렌더링 최소화 가능하지만, 여러 인스턴스 생성 시 싱글톤 문제 발생 → ContextAPI로 여러 Provider를 만드는 방식과 혼합 필요

  • 컨텍스트 사용이 필요한 시점

    before: 설명 없음
    after: 위에서 설명한 상황에 해당

  • 컨텍스트와 구독 패턴 사용하기

    before: 설명 없음
    after: ContextAPI를 통해 subscription 값을 관리

  • 정리

    before: 설명 없음
    after: 컨텍스트와 구독의 혼합 사용으로 prop drilling을 없애서 바로 접근하게 하면서도 선택적 구독을 통해 리렌더링을 최소화합니다.

• 06장: 전역 상태 관리 라이브러리 소개

  before: 설명 없음
  after: 대표적으로 flux 패턴인 zustand와 atom 방식인 jotai가 있음 추가적으로 서버쪽 상태 캐시를 위한 React Query 가있음

  • 전역 상태 관리 문제 해결하기

    before: 설명 없음
    after: 위에서 한 번 언급했듯 컴포넌트가 필요한 값을 공유해야하는데 상요하지 않는 값도 업데이트되면서 불필요한 리렌더링이 발생. 추가로 전역값을 write하는 방법도 어려움.

  • 데이터 중심 vs. 컴포넌트 중심 접근 방식

    before: 설명 없음
    after: 데이터 중심은 컴포넌트 밖에 이미 데이터가 있고 이를 컴포넌트와 연결하는 느낌이라면, 컴포넌트 중심은 컴포넌트에서 해당 상태를 관리하기 위한 설계중심. 컴포넌트가 unmount되면 전역 상태도 사라지게 듬

  • 데이터 중심 접근 방식 이해하기

    before: 설명 없음
    after: 설명 중복

  • 컴포넌트 중심 접근 방식 이해하기

    before: 설명 없음
    after: 설명 중복

  • 두 접근 방식의 예외

    before: 설명 없음
    after: 반드시 둘 중 한 패턴을 선택하는 것이 아니며 하이브리도 가능

  • 리렌더링 최적화

    before: 설명 없음
    after: 객체 값의 일부분 즉 변경된 부분만 컴포넌트가 리렌더링 되기

  • 선택자 함수 사용

    before: 설명 없음
    after: 선택자를 통해 전역 상태에서 원하는 값만 선택

  • 속성 접근 감지

    before: 설명 없음
    after: 잘이해 안감

  • 아톰 사용

    before: 설명 없음
    after: 해당 값을 atom으로 감싸서useAtom을 통해 구독독

  • 정리

    before: 설명 없음
    after: 전역 상태 관리는 불필요한 리렌더링 방지와 상태 갱신 전달 문제 해결에 중점을 둠. 선택자 함수와 atom 등 하이브리드 방식을 통해 최적화 가능

  • 07장: 사용 사례 시나리오 1: Zustand

    before: 잘 모르겠음.
    after: flux패턴. 보일러플레이트를 줄이고 store, subscription을 통해 top-down 방식

  • 08장: 사용 사례 시나리오 2: Jotai

    before: 잘 모르겠음.
    after: atom방식으로 더욱 단순한 방식. 하지만 atom이 많아질수록 관리가 어려워짐 atoms-in-atom과 같은 패턴으로 해결하려고하지만 어려움 bottom-up 방식

  • 09장: 사용 사례 시나리오 3: Valtio

    before: 잘 모르겠음.
    after: 잘 모르겠음.

  • 10장: 사용 사례 시나리오 4: React Tracked

    before: 잘 모르겠음.
    after: 잘 모르겠음.

  • 11장: 세 가지 전역 상태 라이브러리의 유사점과 차이점

    before: 잘 모르겠음.
    after: 세가지 라이브러리 모드 Poimandres라는 같은곳에서 제공된다. 즉 스타일의 차이라는 뜻. 3가지 라이브러리 모두 전역상태를 어떻게 리렌더링을 최소화 하면서 중복을 제거하는지에 대한 공통점이있다.