🐢꾸준함의 미학

마스터클래스_5주차

8 min read

SPA와 MPA Multipage → SPA란? 상태관리 → 어떠한 상태에 의해서 화면의 변경을 모니터링 뷰 모델 바인딩 화면을 어떻게 작게 나눌까, 재사용할까. 변동사항을 탐지하고 리렌더링 변경사항을 탐지하기 위해서는 변경사항과 기존을 비교 diff단계까지도 실제 DOM에서는 따로 갱신이 없고 virtual DOM에서 최소한의 변동 사항을 반영해서 바꿈 → DOM의 접근을 최소화함 가상DOM → DOM을 흉내낸 최소한의 객체로 트리구조로 되어있음

setCount → count값 바꾸는 함수 useState로 정의된 값이 count고 count가 바뀌게 되면

상태관리에서 useState에서 setStat가 호출됐을 때 notify가 호출되고 이를 감지하여 바뀌는 형태

CreateElement의 역할과 동작 원리

JSX를 변환하는 과정에서 파싱(토크나이징 → 렉서 → 파서)

createElement 함수의 역할

  • DOM노드 생성 및 관리
    • 주어진 태그, 속성, 자식 요소들을 조합하여 새로운 DOM 노드 또는 가상 DOM 노드 생성
  • 컴포넌트 구조화
    • 다양한 컴포넌트를 일관된 인터페이스로 제공

createElement함수의 동작 방식

  • 노드 타입 확인
  • 속성 처리
  • 자식 노드 처리
  • vitual DOM 객체 반환

createElement 함수의 최적화

동기적으로 동작할 경우 싱글 스레드인 nodejs가 동기적으로 하는 과정에서 끊기는 현상이 발생할 수 있음 작업을 분할해서 다음 작업이 들어올 여유를 줌. setTimeout을 통해 비동기적으로 처리 리액트는 바닐라보다 느리다

  • 동일한 입력이 오면 또 동일한 Virtual DOM 객체를 반환?
  • 절대 변경이 안되는 노드도 가상 DOM에 있어야 하나?
  • list의 변화를 쉽게 파악하는 방법

Virtual DOM과 Diff 알고리즘

리액트에서는 Virtual DOM 용어를 자체를 잘 안씀 React native도 있고 여러 가지가 있기 때문에 DOM이라는 표현을 자제하고 있음

Virtual DOM을 사용하는 이유

  • DOM 조작의 비용
    • 프론트에서 DOM 조작의 비용이 가장 느림
    • 브라우저의 렌더링 엔진에서 많은 리소스를 소비
    • 페이지 전체를 새로 그리는 데 많은 시간이 소요될 수 있음(첫 페이지에 대한 로딩 문제)

Diff 알고리즘의 동작 원리

두 개의 Virtual DOM 트리 간의 변화를 찾는 과정에서 노드의 타입과 속성을 비교 그 결과 React는 DOM을 효율적으로 갱신

  1. 노드 타입 비교
    1. 노드의 타입이 다르면 해당 노드를 완전히 교체함
  2. 속성(props) 비교
    1. 노드의 타입이 동일한 경우, 그 노드의 속성을 비교하여 달라진 부분만 수정함
  3. 자식 노드 비교
    1. 자식 노드를 탐색?
    2. 리스트 노드를 쉽게 비교하는 방법?

VDOM 업데이트 절차

  • 새로운 Virtual DOM 생성
  • 기존 Vitual DOM과 비교
  • 차이점을 기반으로 실제 DOM 업데이트
    • DOM API를 통한 업데이트
  • 현재 Virtual DOM을 새로운 DOM으로 교체
    • 가상DOM을 쓰는 이유 → DOM조작의 최소화

비교와 동시에 업데이트

  • 방법: 변경 사항을 감지할 때마다 실제 DOM을 업데이트
  • 장점 : 간단하고 구현이 쉬우며 바로 업데이트되므로 빠르게 반응하는 것처럼 보임
  • 변경 사항이 많으면 성능 저하

배치 처리

  • 변경 사항을 모아서 한번에 실제 DOM에 반영
  • DOM 조작
    • DOM 조작을 최소화할 수 있어 성능 향상
    • 리플로우와 리페인트를 줄여 브라우정 성능에 유리

리스트 항목과 key의 diffing

Virtual DOM을 사용하지 않는 방식

컴파일 단계에서 상태가 변경될 때 어떤 DOM 조작이 필요할지 미리 결정하고, 그에 맞춰 최적화된 JS 코드를 생성

함수형 프로그래밍 패러다임

  • 순수 함수(pure-function)
  • 불변성(immutability)
  • 고차함수(higher-order function)
    • 함수를 인자로 받거나 함수를 반환

옵저버 패턴

뷰 간의 의존을 하게 되면 서로 계속해서 상태 관리를 해야 하기 때문에 얽히게 되는 구조가 될 수밖에 없음

Proxy

const target = {
  message: "Hello, World!"
};
 
const handler = {
  get: function(target, prop) {
    return prop in target ? target[prop] : "Property does not exist";
  },
  set: function(target, prop, value) {
    console.log(`Setting value ${value} to ${prop}`);
    target[prop] = value;
  }
};
 
const proxy = new Proxy(target, handler);
 
// 접근 시
console.log(proxy.message); // "Hello, World!"
console.log(proxy.nonexistent); // "Property does not exist"
 
// 값 설정 시
proxy.message = "Hello, Proxy!"; // "Setting value Hello, Proxy! to message"
console.log(proxy.message); // "Hello, Proxy!"

나 → target가 관계가 마치 중간 매개체(proxy)를 거쳐 target으로 이동하는 듯함

사용자가 입력한 값을 모델의 속성에 반영 → 모델이 바뀔 경우 뷰는 리렌더링 → 뷰가 바뀔 경우 렌더링하는 코드를 proxy를 활용해서 target이라는 부분이 모델이 될 수도 있고 뷰를

Object.defineProperty 배열이나

요청과 응답 사이의 과정 → 미들웨어 express 미들웨어의 특징 미들웨어의 순서를 req,res,next라는 표현을 통해 지정할 수 있음. 어떤 주소로 들어왔는지에 대해 제공하는 리소스 → api api들을 조금 더 의미있게 정의할 필요가 있음 api의 구성은 reasonable하게 짜야한다 api ? rest-ful하게 표현할 수 있는명확한 정의 서버측의 동작을 http method로 표현 & resources(Path) method의 이름과 resouce의 이름을 보았을 떄 어떤 응답이 나올지에 대해 시각적으로 충분히 이해할 수 있는 api가 restful한 api임. 정반대 → graphQL(추상화 해서 보냄) http 메서드의 내용과 요청 작업의 주소 부분을 봤을 때 명시적으로 원하는 작업이 무엇인지를 잘 표현하자!

db선택에서의 자유도 RDB의 대표주자가 아닌 다른 db의 대표주자들 써보기 NOSQL, DynamoDB 간단한 db의 경우 서버리스로

그래프 뷰

백링크