Now or Never

Leetcode 2910. Minimum Number of Groups to Create a Valid Assignment

GrapeMilk — Fri, 7 Feb 2025 01:18:26 +0900

- 그룹의 수를 최소화 해야하기 때문에 그룹안에 ball을 최대한 많이 넣어야 한다 (그리디)

- 그룹핑을 할 때 나머지가 있으면 나머지로 그룹을 만들 수 있는지 확인해야 한다.

function minGroupsForValidAssignment(balls: number[]): number {
  const map = new Map<number, number>();
  for (const n of balls) {
    map.set(n, (map.get(n) || 0) + 1);
  }

  let min = balls.length;
  for (const v of map.values()) {
    min = Math.min(min, v);
  }

  // size는 min 값부터 시작 (가장 큰 그룹을 만들 수 있는 크기, 그리디) 
  for (let size = min; size >= 1; --size) {
    const numGroups = groupify(map, size);
    if (numGroups > 0) return numGroups;
  }

  return balls.length;
}

function groupify(map: Map<number, number>, size: number): number {
  let groups = 0;
  const next = size + 1;

  for (const value of map.values()) {
    const numGroups = Math.floor(value / next);
    const remaining = value % next;

    if (remaining === 0) {
      groups += numGroups;
    } else if (numGroups >= size - remaining) {
      // 그룹 하나 더 만들 수 있는지 확인
      // 더 만들 수 있는지 확인에는 next가 아닌 size를 비교. 
      groups += numGroups + 1;
    } else {
      // size로 쪼개질 수 없는 그룹
      return 0;
    }
  }

  return groups;
}

전역 상태 라이브러리를 왜 사용할까?

GrapeMilk — Tue, 4 Feb 2025 23:54:16 +0900

간단한 전역 객체를 만들다가 들었던 생각을 공유해 봅니다.

javascript에서 모듈안에 생성된 객체/배열은 다른 모듈에서 import할 때 새 인스턴스가 생기지 않는다.

예를들어 module.js라는 공유되는 모듈이 있고

module.js

export const arr = [];

A.js 모듈에서 arr를 import한 뒤 숫자 1을 push 하는 코드가 있다.

import { arr } from "./module"; 

arr.push(1);

B.js 모듈에서 arr를 콘솔에 찍어보면 push된 값이 반영된 걸 확인할 수 있다.

// B.js
import { arr } from "./module";

console.log("B.js에서 arr:", arr); // [1] (A.js에서 변경한 값이 반영됨)

참조의 공유

모듈에서 선언한 객체/배열을 export하면 참조를 공유하기 때문에 import 한 모듈사이에서 값을 공유할 수 있게 된다.

(단, let을 통해 값을 "재할당"하면 안됨)

이렇게 모듈 시스템을 통해 간단하게 전역에서 공유하는 객체를 생성할 수 있는데 왜 우리는 전역 상태 라이브러리를 사용할까?

React 상태 관리와 모듈 시스템

여러가지 이유가 있지만 일단 모듈 시스템만으로는 React 상태 관리를 할 수 없다.

모듈로 import한 값이 변경된다고 React 라이프 사이클을 타지 않는다 따라서 상태 변경을 감지하려면 useState나 useEffect와 같이 사용해야한다. 전역 상태 라이브러리는 이런 작업을 내부적으로 구현해서 사용하기 편리하게 제공한다.

Zustand의 경우 내부적으로 구독(subscribe) 시스템을 사용하여 상태 변경을 감지하고 React 컴포넌트를 자동으로 업데이트한다.

아래는 Zustand의 상태 관리 코드의 단순화 버전이라고 하는데(by GPT) 정확한 구현은 시간될 때 뜯어봐야 할 것 같다.

import { useSyncExternalStore } from "react";

// Zustand 내부에서 실행되는 상태 관리 로직
const createStore = (createState) => {
  let state = createState((newState) => {
    state = { ...state, ...newState };
    listeners.forEach((listener) => listener(state));
  });

  let listeners = new Set();

  return {
    getState: () => state,
    setState: (newState) => {
      state = { ...state, ...newState };
      listeners.forEach((listener) => listener(state));
    },
    subscribe: (listener) => {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
  };
};

// Zustand의 상태 변경 감지 로직
const useStore = (selector) => {
  const store = createStore((set) => ({ count: 0, increase: () => set({ count: state.count + 1 }) }));

  return useSyncExternalStore(
    store.subscribe,
    () => selector(store.getState()), 
    () => selector(store.getState()) 
  );
};

useEffect vs useLayoutEffect

GrapeMilk — Fri, 31 Jan 2025 20:55:26 +0900

useScrollRestoration Hook을 구현하면서 발생한 문제를 기록 해봤습니다.

useScrollRestoration훅은 특정 페이지에서 스크롤 이벤트가 발생할 때마다 scrollY값을 sessionStorage에 저장한다.

무한스크롤로 구현된 목록 페이지에서 상세페이지로 이동한뒤 다시 목록에 돌아왔을 때 scrollY값을 유지함으로써 좋은 탐색 UX를 위해 자주 사용되는 기능이다.

이 훅을 구현하면서 발생한 이슈가 있었는데 useEffect vs useLayoutEffect 관점에서 기록해보려고 한다.

useScrollRestoration훅 초기 버전

import { useEffect, useLayoutEffect } from 'react'
import { useRouter } from 'next/router'
import { throttle } from 'lodash-es'

const THROTTLE_TIME = 300

export function useScrollRestoration() {
  const router = useRouter()
  const asPath = router.asPath

  const saveScrollHeight = (asPath: string) => {
    sessionStorage.setItem(
      `scrollHeight:${asPath}`,
      window.scrollY.toString(),
    )
  }

  useEffect(() => {
    const scrollHeight = sessionStorage.getItem(`scrollHeight:${asPath}`)

    if (scrollHeight) {
      window.scrollTo(0, parseInt(scrollHeight, 10))
    }
  }, [])

  useEffect(() => {
    const saveScrollPosition = throttle(() => {
      saveScrollHeight(asPath)
    }, THROTTLE_TIME)

    window.addEventListener('scroll', saveScrollPosition)
    return () => {
      window.removeEventListener('scroll', saveScrollPosition)
    }
  }, [])
}

훅을 구현하고 테스트해보니 sessionStorage에 저장된 window.scrollY 값이 상세 페이지에 진입할 때 0으로 리셋되는 현상이 있었다. 의심되는 부분은saveScrollHeight를 실행하는 scroll 이벤트 부분. clean up 시점에 콘솔을 찍어보니 window.scrollY가 0으로 찍혔다.

console.log를 적용한 코드

  useEffect(() => {
    const saveScrollPosition = throttle(() => {
      saveScrollHeight(asPath)
    }, THROTTLE_TIME)

    window.addEventListener('scroll', saveScrollPosition)
    return () => {
      console.log(window.scrollY, " : debug") // clean up시에 0으로 찍히는 scrollY 값...
      window.removeEventListener('scroll', saveScrollPosition)
    }

왜 이런 현상이 발생할까?

아래 사진 처럼 useEffect의 clean up 시점은 Browser Paint가 발생한 뒤이다.

추측컨데 상세페이지로 이동하면서 Brower paint가 다시 발생했고 변경된 페이지의 scrollY는 0부터 시작하므로(왜 0부터 시작하는지는 파악해봐야 한다, next.js의 기본 동작인 것 같다) window.scrollY는 0으로 다시 그려졌을 것이다. 그 시점의 값을 useEffect의 clean up에 정의한 함수가 참조하면서 sessionStorage의 값도 0으로 바꿨을 것.

Browser paint 이전에 effect를 실행하는 useLayoutEffect로 변경해서 이슈를 해결했다.

...

export function useScrollRestoration() {
  ...
  useLayoutEffect(() => {
    const saveScrollPosition = throttle(() => {
      saveScrollHeight(asPath)
    }, THROTTLE_TIME)

    window.addEventListener('scroll', saveScrollPosition)
    return () => {
      window.removeEventListener('scroll', saveScrollPosition)
    }
  }, [])
}

javascript import overhead

GrapeMilk — Sun, 5 Jan 2025 11:31:55 +0900

es-toolkit의 PR을 구경하다가 bench: remove import overhead 라는 제목의 PR을 보게 됐다.

해당 PR에는 아래와 같은 수정이 있는데 이게 import의 overhead를 어떻게 줄일 수 있는지 궁금해졌다.

그리고 gpt에게 물어봤다.

첫 번째 질문

1번에서 2번으로 코드를 수정했는데 import overhead가 줄었어 어떤 차이야?

1번
import { after as afterToolkit } from 'es-toolkit';
import { after as afterLodash } from 'lodash';

2번
import { after as afterToolkit_ } from 'es-toolkit';
import { after as afterLodash_ } from 'lodash';

const afterToolkit = afterToolkit_;
const afterLodash = afterLodash_;

GPT 첫 번째 답변

1. 첫 번째 코드

import { after as afterToolkit } from 'es-toolkit'; 
import { after as afterLodash } from 'lodash';

이 코드는 es-toolkit와 lodash 모듈에서 각각 after라는 함수를 가져와 직접 afterToolkit과 afterLodash에 할당합니다.
결과:
import 구문은 모듈의 모든 코드를 실행한 뒤, 필요한 부분(after)을 가져옵니다.
만약 두 모듈(es-toolkit과 lodash)이 크거나 불필요한 부분을 포함하고 있다면 초기 로드 시간과 메모리 사용량이 증가할 수 있습니다.

2. 두 번째 코드

import { after as afterToolkit_ } from 'es-toolkit'; 
import { after as afterLodash_ } from 'lodash'; 

const afterToolkit = afterToolkit_;
const afterLodash = afterLodash_;

이 코드는 es-toolkit와 lodash에서 after를 각각 afterToolkit_과 afterLodash_라는 이름으로 가져오고, 이후에 변수 할당으로 afterToolkit과 afterLodash를 정의합니다.
결과:
import 구문은 여전히 모듈을 실행하고 필요한 after를 가져오지만, 변수 할당을 통해 모듈 초기화 과정에서의 직접 참조를 피합니다.

차이가 발생하는 이유

1. 모듈 실행 및 바인딩

첫 번째 코드: afterToolkit과 afterLodash는 직접적으로 모듈에서 가져온 값에 바인딩됩니다. 이런 방식은 모듈 초기화 시점에 더 많은 메타데이터 관리 비용이 발생할 수 있습니다.
두 번째 코드: afterToolkit_과 afterLodash_를 가져온 뒤, 이를 로컬 변수에 다시 할당합니다. 이 과정은 런타임에서 바인딩 메타데이터를 단순화시켜 약간의 오버헤드 감소를 유발할 수 있습니다.

2. V8 엔진 최적화

V8 같은 자바스크립트 엔진은 직접 import한 값과 로컬 변수에 재할당한 값을 다르게 처리합니다.
- 첫 번째 방식은 모듈 네임스페이스 참조 비용이 더 클 수 있습니다.
- 두 번째 방식은 로컬 변수 접근이 더 빠릅니다.

결론

두 번째 방식은 재할당을 통해 import 바인딩의 최적화를 유도하며, 모듈 참조 비용을 줄이는 효과가 있습니다. 따라서 초기화 속도와 런타임 접근 성능에서 약간의 이점을 얻을 수 있습니다.

두 번째 질문

import 구문은 모듈의 모든 코드를 실행한 뒤, 필요한 부분(after)을 가져옵니다. 이 문장을 더 구체적으로 설명해줘

GPT 두 번째 답변

1. 모듈 시스템의 동작 방식

자바스크립트의 **ES 모듈(ESM)**은 다음 단계를 통해 동작합니다:

1.1 모듈 로드 및 파싱 단계

import 구문이 실행되면, 자바스크립트 엔진은 해당 모듈 파일(예: es-toolkit 또는 lodash)을 찾습니다.
모듈 파일을 읽어 들이고 전체 코드를 파싱합니다.
필요한 경우 **의존성(다른 import된 모듈)**도 재귀적으로 로드합니다.

1.2 모듈 실행 단계

모듈이 파싱되면 모든 코드가 실행됩니다.
- 예를 들어, es-toolkit이나 lodash 모듈 안에 함수 정의, 변수 초기화, 객체 생성, 로직 실행 등이 있으면 이들이 모두 실행됩니다.
실행 결과로 모듈의 export 객체가 만들어집니다.
- 이 객체는 모듈이 제공하는 모든 export된 값(함수, 변수, 클래스 등)을 포함합니다.

1.3 필요한 부분 가져오기

import { after } from 'lodash';처럼 부분 import를 사용할 경우, 엔진은 모듈의 export 객체에서 after라는 이름의 값을 찾아 가져옵니다.

2. 실제 동작 예시

2.1 lodash 모듈 구조 (가상 예시)

// lodash/index.js
export const after = (n, func) => { /* 정의 */ };
export const chunk = (array, size) => { /* 정의 */ };
export const cloneDeep = (value) => { /* 정의 */ };

// 추가적인 내부 로직 (모듈 실행 시 실행됨)
console.log('lodash 모듈이 로드되었습니다.');

2.2 import 구문의 동작

import { after } from 'lodash';

위 코드를 실행하면 다음이 발생합니다:

lodash/index.js 파일이 로드되고 전체 코드가 실행됩니다.
- 여기서 console.log('lodash 모듈이 로드되었습니다.');도 실행됩니다.
- after, chunk, cloneDeep 함수가 메모리에 정의됩니다.
실행 결과로 export 객체가 생성됩니다:

{
  after: [Function: after],
  chunk: [Function: chunk],
  cloneDeep: [Function: cloneDeep]
}

3. import { after }는 이 export 객체에서 after를 찾아 가져옵니다.

3. 모듈 실행의 부작용

모든 모듈의 코드를 실행하는 이유는 모듈이 **부작용(side effect)**을 포함할 수 있기 때문입니다.

예시: 부작용이 있는 모듈

// example.js
console.log('Example 모듈 실행 중...');
export const exampleFunction = () => console.log('Hello, world!');

// main.js
import { exampleFunction } from './example.js';

main.js를 실행하면, example.js의 모든 코드가 실행되기 때문에 다음이 출력됩니다:

Example 모듈 실행 중...
이후 exampleFunction만 가져옵니다.

4. 요약

import 구문은 모듈의 전체 코드를 실행하여 필요한 export 객체를 생성합니다.
필요한 부분만 가져오더라도 모듈 전체 실행은 피할 수 없습니다.
따라서 큰 모듈에서는 불필요한 실행 및 메모리 사용이 성능에 영향을 줄 수 있습니다. 이를 최적화하려면 필요한 부분만 export하거나, 로직을 나눠서 import하는 방법이 있습니다.

세 번째 질문

두 번째 코드도 결국 import에서 모든 모듈을 실행하는데 import overhead가 줄어드는 이유는 뭐야?

GPT 세 번째 답변

좋은 질문입니다! 두 번째 코드에서 import overhead가 줄어드는 이유는, 모듈의 실행 자체가 아니라, 변수 접근과 바인딩 방식의 차이에 있습니다. 이를 자세히 설명하겠습니다.

1. 두 코드의 비교

첫 번째 코드:

import { after as afterToolkit } from 'es-toolkit';
import { after as afterLodash } from 'lodash';

두 번째 코드:

import { after as afterToolkit_ } from 'es-toolkit';
import { after as afterLodash_ } from 'lodash';

const afterToolkit = afterToolkit_;
const afterLodash = afterLodash_;

두 코드 모두 모듈 전체를 실행하는 것은 동일합니다. 하지만 import된 값을 사용하는 방식에서 차이가 발생하여 성능에 영향을 미칩니다.

2. import 구문과 바인딩

첫 번째 코드의 동작

import { after as afterToolkit }는 es-toolkit 모듈에서 after를 가져와 모듈 네임스페이스와 강하게 바인딩합니다.
- afterToolkit은 항상 모듈 네임스페이스를 통해 값을 참조합니다.
- 이는 모듈 내부에서 값이 변경될 가능성을 고려한 동작으로, 런타임 시점마다 모듈 네임스페이스를 확인하게 되어 약간의 오버헤드가 발생합니다.

두 번째 코드의 동작

import { after as afterToolkit_ }로 가져온 afterToolkit_은 모듈 네임스페이스와 바인딩되지만, 이후:

const afterToolkit = afterToolkit_;

로컬 변수 afterToolkit에 재할당됩니다.

로컬 변수는 모듈 네임스페이스와의 연결이 끊어지며, 단순히 메모리 주소만을 참조합니다.
로컬 변수 접근은 더 빠르고 메타데이터 오버헤드가 적습니다.

3. 성능 차이의 원인

3.1 모듈 네임스페이스 접근 비용

모듈에서 값을 직접 import할 경우, 엔진은 모듈 네임스페이스 객체를 통해 값을 참조해야 합니다.
- 이 객체에는 export된 모든 값과 관련된 메타데이터가 포함되어 있으며, 이로 인해 접근 비용이 조금 더 높아집니다.
- 특히, 반복적으로 함수나 변수를 호출하거나 참조할 때 이 오버헤드가 누적될 수 있습니다.

3.2 로컬 변수 접근 비용

두 번째 코드에서는 import한 값을 로컬 변수로 재할당했기 때문에, 이후에는 단순히 로컬 스코프의 변수로 접근합니다.
- 로컬 변수는 모듈 네임스페이스와 독립적으로 작동하며, 접근 속도가 더 빠릅니다.
- V8 같은 자바스크립트 엔진은 로컬 변수에 대해 더 효율적으로 최적화를 수행할 수 있습니다.

4. 실제 성능 차이

첫 번째 코드는 모듈 네임스페이스를 통해 값을 참조하기 때문에, 런타임 접근 비용이 조금 더 높습니다.
두 번째 코드는 import된 값을 로컬 변수에 재할당하여, 더 빠른 변수 접근을 가능하게 합니다.
이 차이는 모듈 내 큰 함수 호출이나 반복문에서 더욱 두드러지게 나타납니다.

5. 왜 import overhead가 줄어드는가?

결론적으로, 두 번째 코드에서 import overhead가 줄어드는 이유는 다음과 같습니다:

모듈 네임스페이스 참조 대신 로컬 변수 사용으로 인해 접근 비용이 줄어듭니다.
엔진 최적화가 더 효율적으로 적용됩니다.
- 로컬 변수는 스코프와 메모리 구조가 간단하여 최적화가 빠르게 이루어집니다.
모듈 실행 자체는 동일하지만, 런타임 접근 속도가 개선되어 반복적인 참조에서 성능 향상을 얻을 수 있습니다.

6. 적용 시점

이 방식은 특히 다음과 같은 경우 유용합니다:

모듈에서 가져온 함수나 변수를 반복적으로 사용하는 경우.
성능 최적화가 중요한 대규모 프로젝트에서 미세한 개선이 누적될 때.

for of vs for

GrapeMilk — Mon, 9 Sep 2024 11:15:33 +0900

javaScript에서 for...of와 일반적인 for 루프의 성능 차이는 사용하는 용도에 따라 다르지만 보통 for의 성능이 좋다

1. for

동작 방식: for 루프는 인덱스를 기반으로 배열이나 반복 가능한 객체에 직접 접근한다.
성능: 배열의 길이가 크고 단순히 인덱스를 사용해 값을 순회할 때, 최적화가 잘 되어 있기 때문에 성능 면에서 이점이 있다.

const arr = [1, 2, 3, 4]; 

for (let i = 0; i < arr.length; i++) { 
	console.log(arr[i]); 
}

2. for...of

동작 방식: for...of는 반복 가능한 객체(iterable)에서 값 자체를 순회한다. 배열 외에도 Map, Set 같은 다른 이터러블 객체에도 사용할 수 있다.
성능: for...of는 내부적으로 이터레이터를 생성하고 그 값을 가져오기 때문에, 단순 배열 순회에 대해서는 for 루프보다 약간 느릴 수 있다. 하지만 코드의 가독성과 간결성 면에서는 장점이 있다.

const arr = [1, 2, 3, 4]; 
for (const value of arr) {
	console.log(value); 
}

성능 비교

작은 배열: 배열의 크기가 작을 경우 두 루프의 성능 차이는 미미합니다.
큰 배열: 큰 배열을 순회할 때는 for 루프가 성능 면에서 더 효율적일 수 있다. 특히 반복 횟수가 많을 때는 차이가 더 커진다.
가독성: 성능을 크게 고려하지 않는다면, 가독성 면에서 for...of가 더 직관적일 수 있다.

예시: es-toolkit의 sum 함수를 for..of에서 for로 개선한 PR

for...of가 성능이 느린 이유(이터레이터)

javaScript에서 for...of는 이터러블 객체를 순회할 때 이터레이터(iterator)를 사용한다. 이터레이터는 값을 순차적으로 접근할 수 있는 객체이며, for...of 루프는 이터레이터의 동작을 간결하게 해주는 문법이다.

1. 이터러블과 이터레이터

이터러블은 이터레이터를 반환할 수 있는 객체이다. Symbol.iterator 메서드를 가지며, 이 메서드는 이터레이터를 반환한다. 이터레이터는 next() 메서드를 통해 순차적으로 값을 반환하는 객체이다.

const arr = [1, 2, 3, 4];

// 이터레이터 생성
const iterator = arr[Symbol.iterator]();

console.log(iterator.next()); // { value: 1, done: false }
console.log(iterator.next()); // { value: 2, done: false }
console.log(iterator.next()); // { value: 3, done: false }
console.log(iterator.next()); // { value: 4, done: false }
console.log(iterator.next()); // { value: undefined, done: true }

arr[Symbol.iterator]()를 호출하면 배열의 이터레이터가 반환된다.
iterator.next()는 이터레이터를 통해 값을 하나씩 반환한다.
next() 메서드는 { value, done } 객체를 반환하며, value는 다음 값이고 done은 이터레이션이 끝났는지 여부를 나타낸다.

2. for...of로 이터레이터 사용

for...of는 위와 같은 이터레이터 로직을 내부적으로 자동으로 처리해준다. 즉, 개발자가 직접 next() 메서드를 호출할 필요 없이 값만 쉽게 순회할 수 있다.

const arr = [1, 2, 3, 4];

for (const value of arr) {
  console.log(value);
}

이 코드는 내부적으로 arr[Symbol.iterator]()를 호출하여 이터레이터를 생성하고, next()를 반복적으로 호출해 값을 순차적으로 가져온다.
done이 true가 될 때까지 자동으로 순회가 이루어진다.
이 과정이 index로 단순히 값을 가져오는 for 보다 성능을 느리게 한다.

3. 이터레이터를 수동으로 사용한 for...of의 동작 원리

for...of가 내부적으로 하는 작업을 수동으로 구현한 코드

const arr = [1, 2, 3, 4];

// 이터레이터 생성
const iterator = arr[Symbol.iterator]();

let result = iterator.next();
while (!result.done) {
  console.log(result.value);
  result = iterator.next();
}

위 코드는 for...of와 동일한 결과를 얻을 수 있다. 직접 next()를 호출하고 이터레이션을 제어한다.

리액트에서 "렌더링(rendering)"이란?

GrapeMilk — Fri, 23 Aug 2024 23:07:48 +0900

프론트엔드에서 렌더링은 범용적인 용어이다, 브라우저에서도 리액트에서도 렌더링이 발생한다. 리액트에서 렌더링은 무엇일까?

TL;DR 렌더링이란?

브라우저 DOM을 직접적으로 수정하는 비용을 줄이기 위해 React에서 수행하는 작업이며 브라우저 DOM을 업데이트할 범위를 결정하고 반영하는 과정.

Trigger, Render, Commit

리엑트는 "렌더링과정"을 통해 브라우저 DOM을 업데이트할 범위를 결정하고 반영한다. 여기서 렌더링과정은 "Trigger", "Render", "Commit" 단계로 나뉜다.

Trigger

렌더링을 유발하는 단계로 두 가지 상황이 있다.

1. 앱 시작 초기(initial render)

initial render는 target DOM node(root)와 함께 createRoot를 호출한 뒤 render 함수를 실행하는 과정이다.

* createRoot는 인수로 전달된 요소를 리액트 앱의 루트로 만들어 반환한다. 트리 형태의 Virtual Dom에서 루트 요소가 된다.

import Image from './Image.js';
import { createRoot } from 'react-dom/client';

const root = createRoot(document.getElementById('root'))
root.render(<Image />);

렌더링 결과 (공식문서 참고)

2. state의 변경이 있을 때(re-render)

initial render 이후에는 set(State) 함수를 통해 state를 변경하여 리렌더링 할 수 있다.

Render

화면에 그릴 요소를 계산하기 위해 리엑트는 components를 호출하는데 이를 Rendering 이라고 한다.

- initial render에서는 root component를 호출한다.

- 리렌더시에는 state가 변경된 component를 호출한다.

이런 호출은 재귀적으로 반복된다. 호출된 컴포넌트가 다른 컴포넌트를 return 한다면 리액트는 다음 스텝으로 return된 컴포넌트를 렌더한다. 이 호출은 더이상 반환되는 컴포넌트가 없을 때까지 반복된다. 이런 과정을 통해 리액트는 어떤 요소를 하면에 그려야 하는지 알 수 있다.

// Gallery.js

export default function Gallery() {
  return (
    <section>
      <h1>Inspiring Sculptures</h1>
      <Image />
      <Image />
      <Image />
    </section>
  );
}

function Image() {
  return (
    <img
      src="https://i.imgur.com/ZF6s192.jpg"
      alt="'Floralis Genérica' by Eduardo Catalano: a gigantic metallic flower sculpture with reflective petals"
    />
  );
}

// index.js

import Gallery from './Gallery.js';
import { createRoot } from 'react-dom/client';

const root = createRoot(document.getElementById('root'))
root.render(<Gallery />);

- 리액트는 initial render에서 section, h1, 세개의 img Dom nodes를 생성한다.

- 리렌더시에는 이전 렌더와 현재 렌더를 비교하여 변화된 부분을 계산한다.

Commit

Render 단계를 통해 호출된 컴포넌트들이 브라우저 DOM에 적용되는 단계.

- initial render시에는 DOM API인 appendChild() 함수를 사용하여 render를 통해 생성한 노드들을 돔에 반영한다.

- 리렌더시에는 변화된 부분만 DOM에 반영한다.

리액트는 render시에 변화된 부분이 있는 경우에만 DOM을 업데이트한다.

아래에는 부모에게 time 값을 전달받아 props가 변경되어 리렌더링이 일어나는 Clock 컴포넌트가 있다. 매초마다 변경된 time을 받기 때문에 Clock도 매초마다 리렌더링된다. 이 때 input 컴포넌트에는 변화가 없다. 리액트는 이전, 이후 렌더에서 input 컴포넌트에 변화가 없다고 판단하기 때문에 input에 어떤 값을 입력해도 리셋되지 않는다.

export default function Clock({ time }) {
  return (
    <>
      <h1>{time}</h1>
      <input />
    </>
  );
}

Browser paint

리엑트가 렌더링을 마치고 DOM을 업데이트 한 뒤, 브라우저는 화면을 repaint 한다. 즉 "브라우저 렌더링"이 시작된다.

ref

리액트 공식문서, https://beta.reactjs.org/learn/render-and-commit)

직접 답변한 커리어리 글 https://careerly.co.kr/qnas/1400

HTTP 요청 생성 및 분석

GrapeMilk — Fri, 23 Aug 2024 01:59:58 +0900

nc example.com 80

nc (netcat) 명령어를 터미널에 입력하면 간단하게 TCP 연결을 생성할 수 있다.

GET / HTTP/1.0
Host: example.com

그 다음 GET 요청을 작성한 뒤 엔터를 누르면 response를 받을 수 있다.

nc & http 요청 결과

터미널에서 명령어를 통해 간단하게 TCP 연결 및 HTTP 요청을 수행했다! HTTP 요청과 응답을 하나씩 뜯어보면

request header 분석

GET / HTTP/1.0

GET: HTTP method를 의미

/: 요청 url

HTTP/1.0: HTTP 버전

Host: example.com: 요청 도메인 이름

response header 분석

HTTP/1.0 200 OK

HTTP/1.0: HTTP 버전

200 OK: 응답 상태 코드

그 외 key:value 형식으로 다양한 응답값이 있다.

response에는 header와 payload가 존재한다. payload는 위의 사진에 일부 잘린 html이며 header와 엔터로 구분된다.

HTTP 1.0과 1.1

HTTP 1.0은 많은 단점이 있는데 그 중 하나는 multiple request가 되지 않는 것이다. 위에서 실습한 nc 명령어에 HTTP 버전을 1.1로 바꾸면 request한 뒤 한번더 요청이 가능하다. (1.0으로 연결하면 한 번 요청을 보내고 연결이 끊어진다) 이러한 단점은 TCP handshake 시간지연에 따른 비효율로 1.1에서 개선되었다.

(Graphql Apollo) dataIdFromObject와 keyFields

GrapeMilk — Thu, 22 Aug 2024 17:11:42 +0900

deprecated된 dataIdFromObject를 keyFields로 변경하면서 생긴 이슈 기록

Apollo Graphql은 Object 타입을 캐시할 때 기본 식별자로 id 필드를 사용한다. Object에 id필드가 없거나 다른 필드를 식별자로 사용하고 싶은 경우 커스텀 할 수 있다.

Configuring the Apollo Client cache

keyFields: ["title", "author", ["name"]],

www.apollographql.com

그 때 사용하는 것이 dataIdFromObject 함수 또는 KeyField이다.

공식문서에서는 dataIdFromObject의 세 가지 결점을 이유로 KeyFields 사용을 권장한다.

dataIdFromObject의 세 가지 결점

1) It's sensitive to aliasing mistakes.

2) It does nothing to protect against undefined object properties.

3) Accidentally using different key fields at different times can cause inconsistencies in the cache.

오늘 기록할 이슈는 dataIdFromObject의 2번째 결점과 관련이 있다.

keyField로 변경하기 전 다음과 같이 dataIdFromObject 코드를 사용하고 있었다.

 dataIdFromObject(responseObject) {
    switch (responseObject.__typename) {
      case 'Book':
        return `Path:${responseObject.slug}`
      case 'LessonNote':
        return `LessonFile:${JSON.stringify(responseObject)}`
      case 'Course':
        return `KDCCourseInfo:${responseObject.courseId}`
      default:
        return defaultDataIdFromObject(responseObject)
    }
  },

Book 타입은 id가 따로 없기 때문에 고유한 slug 필드가 식별자로 사용될 수 있도록 작업되어 있었고, keyField를 사용하여 다음과 같이 변경해주었다.

Book: {
  keyFields: ['slug'],
},

keyFields을 바꾸니 갑자기 Book 상세 페이지 데이터를 가져오는 Query에서 에러가 발생했다.

Uncaught Invariant Violation: Missing field 'slug' while extracting keyFields from {"__typename":"BookDetail"}

같은 조건에서 바뀐건 dataIdFromObject -> keyFields 밖에 없었기 때문에 코드를 다시 되돌리니 에러는 발생하지 않았다.

그런데 되돌린 코드의 쿼리 요청을 보니 상세페이지에 접근할 때 마다 캐싱된 데이터를 사용하지 않고 계속 서버에 데이터를 요청해서 받아오고 있었다.

에러 로그를 다시 확인해봤다. Book 타입이 아닌 BookDetail 타입을 가져오는 과정에서 slug를 찾지 못하고 있었다. 갑자기 BookDetail 관련 에러는 뭐지..?

BookDetail은 Book을 implement한 타입이다. 이를 통해 interface에 keyFields를 적용하면 implements의 식별자도 변경되는 것을 알 수 있었다. dataIdFromObject를 사용할 때는 typename을 'Book'으로 특정하고 있었기 때문에 slug 식별자로 변경한 코드는 BookDetail에 적용되지 않았다. keyFields를 적용한 순간 implements인 BookDetail도 식별자가 수정되었고, slug 필드를 갖고있지 않았기 때문에 에러를 발생시키고 있었다. BookDetail 타입에 slug를 추가하면 문제는 해결된다. 하지만 캐싱을 못하는건 뭐람..?

알고보니 이전 코드인 dataIdFromObject를 사용했을 때부터 있던 이슈였다. BookDetail 타입은 id를 식별자로 사용하고 있었는데 막상 필드에서는 id를 요청하고 있지 않았다. 즉, 상세 페이지의 데이터가 캐싱되지 않고 항상 Query를 재요청하고 있던 것이다. keyField를 사용했다면 id가 없을 때 에러를 발생시켰겠지만 dataIdFromObject의 특성상 undefined인 식별자 필드를 무시해서 데이터는 캐싱되지도 않고, 캐싱된 데이터를 찾을 수도 없었다.

What Is Presigned Url

GrapeMilk — Sun, 18 Aug 2024 15:54:43 +0900

Presigned Url

A Presigned URL is a URL that provides temporary, secure access to a specific resource in cloud storage (like Amazon S3) without needing the client to have full access credentials. It is commonly used in scenarios where a client needs to upload or download files directly to/from cloud storage, while the server still controls access.

How Presigned URLs Work

When a presigned URL is generated, it includes:

The resource's location (bucket, key, etc.).
A signature created using the server's access credentials.
A defined expiration time, after which the URL becomes invalid.

The server typically generates this URL, embedding the necessary permissions and expiration time into it. The client can then use the URL to directly upload a file (for a PUT request) or download a file (for a GET request) without needing further authentication.

Common Use Cases

Direct File Uploads: Allow users to upload files directly to cloud storage from their browser or application without routing through your server, reducing load and complexity.
Secure File Sharing: Temporarily grant access to a file (like a report or media file) without exposing your credentials or full access permissions.
API-Driven File Access: In microservices or serverless architectures, presigned URLs can be used to allow other services to interact with specific resources securely.

Benefits

Security: Access is restricted by both permissions and expiration time.
Performance: Clients upload or download files directly from storage, reducing server bandwidth and processing load.
Simplified Permissions: You don’t need to manage complex access controls for each client interaction—just generate the presigned URL with the right permissions.

Limitations

Temporary Access: The URL is only valid for a limited time.
Sensitive Handling Required: If the URL is exposed, unauthorized users can access the resource until it expires.

In summary, a presigned URL is a powerful tool for secure, temporary access to cloud storage resources, enabling efficient file transfers and fine-grained control over access.

서버의 이미지 serving 부담을 줄여주고 클라이언트가 직접 파일 업로드함으로서 파일명 수정등의 소통비용도 줄일 수 있는 것 같다.

20240814 TIL

GrapeMilk — Wed, 14 Aug 2024 01:49:18 +0900

React Graphql Masterclass

32. Data Resolver - Overriding A Field

GraphQL 서버는 graphql 요청시 scalar 타입이면 값을 그대로 response하고 object 타입이면 object 타입의 각 필드마다 관련된 매핑 함수가 있는지 확인한다.

예를 들어 아래와 같은 데이터 구조에서

type Query {
    sayHello: String
    customers: [Customer]!
}

type Customer {
    id: ID
    name: String
    age: Int
    city: String
}

public class Customer {
    private Integer id;
    private String name;
    private Integer age;
    private String city;;
}

쿼리 요청시에 sayHello 필드는 string을 바로 내려주지만, Customer 필드를 확인할 때 해당 필드는 Object 타입이므로 각 필드가 scalar를 리턴해도 관련 매핑 함수가 있는지 확인한 뒤 실행한 값을 내려준다.

아래와 같은 age관련 함수가 있다면 항상 100을 내려줄 것이다.

    @SchemaMapping(typeName = "Customer")
    public Mono<Integer> age() {
        return Mono.just(100);
    }