2주차 스터디 (4~6장) | Inside React Study

4장 - 상태와 반응성 돌아보기

책 80p

뷰 (프리젠테이션 레이어)

모델

중재자

책 85p

정의

필요한 이유

사용자 상호작용(클릭, 리스트 추가/삭제 등)에 따라 UI 상태를 바꾸려면 자바스크립트로 DOM을 직접 업데이트해야 함 → 상태 변경과 DOM 수정 코드가 점점 복잡해지고 커지게 됨
반응성을 활용하면 비즈니스 로직은 상태와 그 변경에만 집중하면 되고, 상태 변화에 따라 UI는 자동으로 동기화됨

구현 방법

책 85p

책 96p

정의

데이터 흐름

유저 입력:
- 인터렉션 발생 시, 뷰는 데이터바인딩을 통해 자신과 연결된 뷰모델의 특정 메소드 호출
- 뷰모델은 호출된 내용을 바탕으로 모델에게 상태 변경 요청
상태 변경:
- 상태 변경된 모델은 관찰자 패턴을 이용해 뷰모델에게 통지 → 뷰모델에서 자신의 상태 업데이트
- 뷰에서는 뷰모델의 상태 변경을 감지하고 UI 업데이트

책 97p

뷰와 뷰모델의 데이터를 자동으로 동기화해주는 매커니즘

단방향 바인딩
- 데이터가 뷰모델에서 뷰로 한쪽 방향으로만 흐름
- 뷰모델 상태가 변경되면 뷰 UI 업데이트, But 뷰에서 발생된 변경이 뷰모델 상태를 자동으로 변경 x
- 라이브러리 예시 : React
양방향 바인딩
- 데이터가 뷰모델/뷰 사이를 자유롭게 흐름
- 뷰모델 상태가 변경 → 뷰 UI 업데이트 / 뷰 변경 → 뷰모델 상태 변경
- 라이브러리 예시 : Vue v-model

<br />

v2, v3
- 각 패키지마다 개별 node_modules 디렉터리를 생성
- 중복 의존성이 많아 설치 시간과 디스크 사용량이 큼
최신 버전
- 의존성을 최대한 평탄화(flattening) 하여 중복 설치를 줄임
- 설치 속도와 용량은 개선되었으나, Phantom Dependency 문제 발생 가능

yarn
- Yarn Classic (v1)
  - npm 대비 병렬 설치로 더 빠른 설치 속도
  - 의존성 평탄화 방식 사용 → Phantom Dependency 문제 존재
- Yarn Berry (v2 이상)
  - PnP(Plug’n’Play) 개념 도입
  - node_modules 디렉터리를 생성하지 않음
  - 프로젝트 의존성 그래프를 .pnp.cjs 파일에 저장
  - 각 패키지를 .yarn/cache에 zip 파일 형태로 관리
  - 런타임에 PnP 로더가 zip 파일을 직접 참조해 의존성 해결
  - → 빠른 설치, 엄격한 의존성 관리 가능
pnpm
- 패키지를 전역 저장소에 단일 복사본으로 저장
- 프로젝트의 node_modules는 심볼릭 링크(hard link / symlink) 로 구성
- 중복 설치 최소화 → 디스크 효율 + 빠른 설치
- 원본은 전역 스토어에 저장하고, 이를 심볼릭 링킹하기 때문에 Phantom Dependency 문제 X

Vite가 수정된 모듈만 Native ESM 방식을 이용해 브라우저에 전달 → HMR 속도 빠름
Native ESM =브라우저에서 ES 모듈을 직접 불러올 수 있게 해주는 기능
- 어떤 모듈이 수정되면 브라우저는 Vite로부터 HTTP 요청을 보내 수정된 모듈만을 받아 교체
- 이때 의존성이 있는 패키지는 캐시에서 가져오므로 HMR 속도가 빨라
- Vite는 전 과정에서 ESM을 활용하므로 추가적인 번들링 프로세스 없이 소스 코드 갱신 속도가 빠름

<br />

기존 프로그래밍 언어(GPL)의 문법 확장 (= 표준 X)
동작 환경: 기존 언어의 런타임 환경 내에서 실행
요구사항: 기존 언어의 런타임만 필요
ex. JSX
- js 안에서 XML/HTML과 유사한 문법을 사용하여 리액트 엘리먼트를 표현하는 구문확장
- js 내부 DSL → babel 등 별도 컴파일러 필요