journey-dev

Webpack 설정으로 알게된 publicPath, historyApiFallback

journey-dev — Sun, 16 Mar 2025 02:10:40 +0900

최근 사이드 프로젝트에서 웹팩을 직접 설정해보며, 웹팩의 다양한 속성들을 학습해보았다.

웹팩 설정을 하며 배운것들이 너무너무 많다.

웹팩 설정을 통해 할 수 있는 것들이 그렇게나 많다니..!

그 과정에서 특히 기억하고 싶은 publicPath와 historyApiFallback에 대해 기록해보려 한다.

✅ publicPath에 대해

`publicPath`는 브라우저가 번들링된 파일들(JavaScript, CSS, 이미지 등)을 어디서 찾아야 하는지 알려주는 기본 경로이다.
publicPath: '/'는 브라우저에게 모든 에셋을 서버의 루트 경로에서 찾아주라고 지시하는 것이다.

SPA에서는 일반적으로 `publicPath: '/'`를 사용하게 된다.
SPA는 클라이언트 측에서 라우팅을 처리하지만, 모든 라우트에서 하나의 동일한 HTML, JS파일을 사용하기 때문이다.
때문에 어떤 라우트에 있든, 클라이언트 측 라우터가 에셋 경로를 루트 경로로 올바르게 요청할 수 있는 것이다!

webpack.config.js에서의 publicPath

✔️ 문제) publicPath 설정이 없을 때 발생하는 오류

처음에 웹팩의 output 설정에서 publicPath를 지정하지 않고 프로젝트를 진행했다.

그 결과, 특정 경로에서 새로고침을 할 때 404 오류가 발생했다.

예를 들어, /movie/123 경로에서 새로고침을 하자 아래와 같은 오류가 발생한다.

"bundle.js"가 상대경로로 붙여있음

bundle.js 파일 경로가 상대경로로 되있어, /bundle.js가 아니라 /movie/bundle.js로 찾게됨.

publicPath가 설정되지 않으면, 기본값은 상대경로(./ 또는 "")이고, 이로 인해, bundle.js의 경로가 상대경로로 지정되어 있다.

때문에 브라우저는 http://localhost:3000/movie/bundle.js 경로에서 bundle.js를 찾으려고 한다.

루트 경로의 movie폴더에서 bundle.js파일을 찾는 것이다.

그러나 웹팩이 빌드한 bundle.js는 dist 폴더 내에 위치하기 때문에 잘못된 경로 요청을 하게되어 404 오류가 발생한다.

✔️ 해결) publicPath : "/" 설정

이 문제를 해결하기 위해 publicPath : "/" 설정을 추가하여 모든 에셋의 경로가 루트 경로('/')를 기준으로 로드되도록 처리해주었다.
모든 에셋의 경로가 루트 경로를 기준으로 하는 절대 경로가 되는 것이다.

※ publicPath: '/'에서 말하는 "루트 경로"란?
웹팩이 빌드를 후 생성된 정적 파일들이 위치한 dist폴더를 만한다.

- 빌드 전: app/src, app/public, webpack.config.js 등
- 빌드 후: app/dist/bundle.js, app/dist/index.html, app/dist/other-assets/...

publicPath: '/' 설정을하면, 개발서버는 dist폴더를 정적 파일을 서빙하는 루트 폴더로 설정한다.
즉, 웹팩에서 설정한 "publicPath : /"는 개발서버가 dist 폴더를 루트로 인식하고, 그 안에 있는 모든 에셋을 로드하라는 지시인 것이다!

때문에 어떤 라우트에서 새로고침을 해도 에셋을 안정적으로 로드할 수 있게 된다.

이제 `/movie/123` 페이지에서도 브라우저는 항상 루트 경로에서 에셋을 찾으므로

http://localhost:3000/bundle.js로 정확하게 파일을 요청하게 된다.

이렇게 어떤 라우트에서든 새로고침을 하더라도 올바른 경로에서 파일을 찾을 수 있게 되는 것이다.

/절대경로로 루트 경로에서 시작되도록 처리

✅ historyApiFallback 에 대해

위에서 spa의 특성으로 인해 publicPath 설정이 필요했는데,

historyApiFallback 설정도 spa의 특성과도 연관이 있다는 것을 알게되었다.

✔️ historyApiFallback란?

SPA에서 존재하지 않는 URL로 접근시, 404 대신 index.html을 제공하여, 클라이언트 사이드 라우팅이 정상적으로 작동하게 해주는 설정이다.

"/movie/123"과 같은 경로는 React Router같은 클라이언트 사이드 라우팅 경로고, 실제 서버에선 이 경로로 파일이 없다.

때문에 브라우저가 서버에 "/movie/123"경로를 요청하면, 서버는 404 에러를 일으키게 된다.
이때 historyApiFallback를 통해 404에러시 자동으로 index.html로 리다이렉트 시켜주는 것이다.
그러면 React앱이 다시 로드되고, React Router를 통해 현재 URL에 맞는 컴포넌트가 렌더링된다.

✔️ historyApiFallback와 publicPath

이렇게 historyApiFallback와 publicPath를 제대로 세팅해야 SPA 앱이 올바르게 리소스를 가져올 수 있게 된다.

   - publicPath: '/' : 모든 에셋(JS, CSS, Html, 등)을 루트 경로 기준으로 로드
   - historyApiFallback: true : 없는 경로 요청 시 index.html로 폴백 처리

   1. 사용자: '/movie/123' 새로고침
   2. 서버: 이 경로는 없는데? -> historyApiFallback 발동
   3. 서버: index.html 반환
   4. 브라우저: index.html 로드
   5. index.html: publicPath='/'에 의해 루트 경로에서 모든 에셋 로드
   6. React Router: '/movie/123' URL을 보고 해당 컴포넌트 렌더링

✅ 느낀점

웹팩이 단순히 번들러 역할을 넘어서, 파일 경로 문제까지도 해결할 수 있다는 것을 알게되었다.
특히 spa는 클라이언트 측 라우팅을 사용하다보니, 서버에서 리소스 로딩 방식을 직접 명시적으로 설정해줘야 함을 알게되었다!
이렇게 웹팩을 직접 구성해보면서, 앱이 작동되는 원리에 대해 좀 더 이해할 수 있는 계기가 된 것 같다.

https://webpack.kr/configuration/output/#outputpublicpath

https://webpack.kr/configuration/dev-server/#devserverhistoryapifallback

클로저를 활용해 useState Hook 직접 구현해보기

journey-dev — Sun, 2 Mar 2025 19:15:58 +0900

✅ 들어가며

javascript deep dive를 읽으며 js코어 개념을 익히곤했다.

그러나 나는 이 개념이 실제 어떻게 실무에서 쓰이고 있는지, 또 어떻게 활용을 해야하는지 늘 의문이였다.

특히 클로저는 변수를 은닉화 할 때 쓴다고 하는데, 은닉을 활용하면 더 코드를 파악하기 힘들지 않을까란 의문이 있었고
이걸 활용하게 될 날이 올까란 생각도 있었다.

그런데 이미 리액트 useState가 클로저를 활용한 개념이라고 한다!

아래 글은 JSConf 의 useState관련 영상을 보며 공부한 내용이다.(※ 영상)

✅ useState와 클로저

1️⃣ 클로저란 무엇인가?

클로저(Closure)는 내부함수가 외부 함수의 변수에 접근할 수 있도록 해주는 JavaScript 기능이다.

클로져를 통해 함수가 “privte”한 변수를 갖을 수 있게 해준다. (변수 은닉화)

즉, 클로저를 사용하면 외부 함수의 변수들이 내부 함수에서 계속 유지되며, 외부 함수의 실행이 종료되더라도 해당 변수에 접근할 수 있게되는 것이다.

클로저 예제코드

function getAdd() {
  let foo = 1; // 클로저로 접근가능
  return function () {
    foo += 1;
    return foo;
  };
}

const add = getAdd();
console.log(add()); // 2
console.log(add()); // 3
console.log(add()); // 4

getAdd 함수는 내부에 foo라는 변수를 가지고 있고, 반환되는 함수는 foo에 접근하고 수정한다.

foo는 add 함수가 호출될 때마다 갱신된다.

2️⃣ 클로저 개념을 활용한 리액트 useState 만들기

리액트의 useState 는 내부적으로 클로저를 사용하여 상태를 관리를 한다.

이 원리를 알아보기 위해 직접 useState를 만들며 알아보겠다.

우선, 클로저가 없다면 어떤 오류가 나오는지 먼저 살펴보자.

2-1. 클로저를 사용하지 않은 useState 예시

function useState(initVal) {
  let _val = initVal;
  const state = _val; // 클로저 사용X
  const setState = newVal => {
    _val = newVal;
  };
  return [state, setState];
}

const [count, setCount] = useState(1);
console.log(count); // 1
setCount(2);
console.log(count); // 1 (변경되지 않음)

setState(2)를 실행해도, count는 여전히 1로 고정된 값이 나온다.

setState는 _val을 업데이트하는 함수이지만, state는 useState가 처음 실행될 때 _val의 값을 그대로 가져와 복사된 값을 유지하기 때문이다.

state는 클로저를 사용하지 않았기 때문에, useState 함수 실행이 끝난 후 상태 값이 가비지 컬렉션에 의해 삭제된다.

2-2. 클로저를 사용한 useState 구현

function useState(initVal) {
  let _val = initVal;
  const state = () => _val; // 클로저를 사용하여 _val을 동적으로 반환
  const setState = newVal => {
    _val = newVal;
  };
  return [state, setState];
}

const [count, setCount] = useState(1);
console.log(count()); // 1
setCount(2);
console.log(count()); // 2 (변경됨)

클로저를 사용하면 state는 최신 값을 동적으로 가져올 수 있다.

외부 함수인 useState가 종료된 후에도, 내부 함수인 state와 setState는 외부 함수의 실행 컨텍스트에 있는 변수 _val을 계속 참조할 수 있다. 때문에 _val은 가비지 컬렉션의 대상이 되지 않고, 계속해서 상태 값으로 유지된다.

이렇게 state는 _val를 클로저로 참조하고 있기 때문에 state()를 호출하면 최신 값을 동적으로 가져올 수 있는 것이다.

2-3. 컴포넌트에서 useState Hook 사용하기

리액트 컴포넌트는 여러 useState를 배열에 저장하고, 이를 통해 여러 상태를 관리하게 된다.

이 과정에서 각 useState 호출은 클로저로 관리되는 상태 값들을 지속적으로 참조하게 된다.

const React = (function () {
  let hooks = [];
  let idx = 0;

  function useState(initVal) {
    const _idx = idx;
    const state = hooks[idx] || initVal;
    const setState = newVal => {
      hooks[_idx] = newVal;
    };
    idx++; // 인덱스를 증가시켜서 다음 훅을 처리
    return [state, setState];
  }

  function render(Component) {
    idx = 0;
    const C = Component();
    C.render();
    return C;
  }

  return { useState, render };
})();

function Component() {
  const [count, setCount] = React.useState(1);
  const [text, setText] = React.useState('apple');

  return {
    render: () => console.log({ count, text }),
    click: () => setCount(count + 1),
    type: (word) => setText(word),
  }
}

var App = React.render(Component); // { count: 1, text: "apple" }
App.click();
var App = React.render(Component); // { count: 2, text: "apple" }
App.type('pear');
var App = React.render(Component); // { count: 2, text: "pear" }

1) hooks, idx , _idx는 클로저로 작동된다.
이 값들은 외부 함수(React 즉시실행함수)에서 정의되었고, 내부 함수인 useState와 render에서 참조하고 있다.
해당 값을 참조하고 있는 곳이 있으므로 가비지 컬렉팅 되상이 되지 않아 값이 유지된다.
클로저 덕분에 외부함수(React 즉시실행함수)가 실행이 끝나도, hooks와 idx는 가비지 컬렉팅되지 않고, 상태 값들을 계속 유지할 수 있다.
때문에 내부함수(useState , render)도 이 값에 계속 접근할 수 있는 것이다.

2) 클로저를 활용한 setState 인덱스 고정
setState가 호출될 때마다 인덱스가 변동되는 문제를 해결하기 위해 클로저를 이용해 state 할당 당시의 인덱스를 고정한다.
count는 0인 idx를 갖고, text는 1인 idx를 갖게된다.
hooks 배열은 [count, text] 가 저장되고 각 hook은 고정된 idx를 통해 접근할 수 있는 것이다.
이런 방식으로 각 상태가 의도한 배열 위치에 정상적으로 저장되고 업데이트 되는 것이다.

✅ Hooks 규칙에 대해

위 코드에서 React 컴포넌트와 Hooks를 직접 만들면서 왜 hooks를 배열로 만들어야 하는지와 hook규칙의 이유에 대해 알 수 있었다.

이에 대해 좀 더 설명하자면 이렇다.

1. hooks 배열과 인덱스 관리를 통해 hook이 실행된다.

위의 “클로저를 활용한 setState 인덱스 고정” 에서 말한 것 처럼 hook은 “고정된 idx”를 가지고 이 인덱스를 통해 상태 값을 관리한다.

나아가 React는 하나의 렌더링 사이클 동안 호출된 모든 hooks를 “배열”에 저장한다.

이렇게 hooks 배열에서 상태의 저장 위치가 고정된 idx를 통해 보장되는 것이다.

이를통해 hooks가 여러개 있을시 hook의 실행 순서를 보장하고, 여러 상태 관리를 순서대로 저장할 수 있다.

2. Hooks 규칙이 있는 이유 : hook 호출 순서 보장 위해

function MyComponent() {
  const handleClick = () => {
    const [state, setState] = React.useState(0); // ❌ React Hook 규칙 위반
    console.log(state);
  };

  return <button onClick={handleClick}>Click Me</button>;
}

리액트는 Hooks는 항상 컴포넌트의 최상위에서만 호출되어야 하는 규칙이 있다.

그 이유는 렌더링될 때마다 Hook의 호출 순서를 보장하기 위해서다.

렌더링이 일어날 때마다 Hooks가 일정한 순서로 호출되어야만,

각 Hook이 배열에 저장된 상태값을 올바르게 참조하고, 상태를 업데이트할 수 있게된다.

<이 hook의 규칙을 어긴다면?>

만약 이 규칙을 어기고 조건문이나 반복문 안에서 Hook을 호출한다면, 매 렌더링마다 Hook의 호출 순서가 바뀔 것이다.

이렇게되면 hooks 배열에 상태 값이 저장되는 순서가 깨지므로, hook의 실행 순서가 달라지게 될 것이고

상태 값들이 올바르게 참조되지 않거나 업데이트되지 않게 된다.

예를들면, 위의 ‘컴포넌트에서 useState hook 사용하기’ 예제에서

hooks 배열은 [count, text] 순서로 저장되어 count와 text를 각각 고유한 인덱스 0, 1에 할당한 상태이다.

여기서 만약 count 상태의 useState hook의 호출이 조건부로 실행이 된다면 이 고유한 idx값이 틀어지게된다.

text useState의 idx가 0이될때도 1이 될때도 있게되어 hook의 호출 순서가 깨진다.

때문에 hooks 배열에 올바른 상태를 참조하지 못하거나 상태를 제대로 업데이트 하지 못하게 되는 것이다.

(text 상태를 참조했는데 idx 0인 count값이 참조될 수도 있고, setText로 상태 업데이트시 count값을 업데이트 해버리는 오류 발생!)

✅ 마치며

useState와 클로저의 원리에 대해 배우며

리액트에서 빈번히 사용되는 개념에 이러한 js코어 원리가 담겨있다는 것을 알고 코어 개념의 활용을 알 수 있었다.

또한 hook의 규칙의 의미까지 알게되었다.

여태까진 맹목적으로 규칙이 있으니 따라왔는데, 그 규칙의 원리까지 알게되어 좀 더 리액트를 이해할 수 있게되었다.

나아가 hook이 배열에 일일히 다 기억되고 있다는 것도 흥미로웠다.

내부 동작을 알기 전엔 리액트가 다 알아서 해주니 약간 매직처럼 느껴졌는데

이렇게 리액트가 한땀한땀 열일하고 있었구나라는 생각이 든다.

Controlled vs Uncontrolled (input요소 value와 defaultValue 차이)

journey-dev — Sun, 16 Feb 2025 19:57:31 +0900

React에서 input 요소를 사용할 때 value와 defaultValue는 어떤 차이가 있을지 의문이 들었다.

단순히 보기엔, defaultValue는 초기값 설정해주는 것 같은데 이런건 또 언제 써야하는걸까?

찾아보니 이 둘의 차이는
Controlled Component(제어 컴포넌트) 와 Uncontrolled Component(비제어 컴포넌트) 라는 것과 관련된 것 이였다.

이건 또 뭐지! 이 두 방식의 차이에 대해 살펴보자.

<요약>
리액트에서 input과 같은 폼 요소를 다룰때,

Controlled 컴포넌트는 value에 state를 넣어 상태를 관리한다.
상태가 업데이트될 때마다 폼 전체가 리렌더링된다.

Uncontrolled 컴포넌트는 defaultValue로 값을 설정하고, ref를 사용해 DOM에 직접 접근하여 값을 관리한다.
상태를 사용하지 않아서 리렌더링 횟수를 줄여 성능을 개선할 수 있다.

✅ Controlled vs Uncontrolled

React에서는 폼 요소의 상태를 관리하는 두 가지 방식이 있다.

state와 통합하는 방식인 Controlled Component 와 DOM을 직접 제어하는 방식인 Uncontrolled Component 이다.

1️⃣ Controlled Component (제어 컴포넌트)

input 초기값을 value로 설정하고,
폼 요소(input)의 값(value)을 state를 통해 관리하는 방식이다.
onChange 이벤트 핸들러를 통해 입력값을 업데이트된다.
장점
- 상태 변경에 따라 UI가 업데이트되어 , 상태와 입력값이 동기화된다.
- state만 관리하면 되서 폼 데이터를 다루기 쉽다.
단점 : 상태 업데이트에 따라 리렌더링이 발생해서 성능 문제생길 수 있다.

import { useState } from 'react';

function ControlledInput() {
  const [text, setText] = useState(''); // React state로 값 관리하고

  return (
    <div>
      <input
        type="text"
        value={text}  // state가 input 값이 됨.
        onChange={event => setText(event.target.value)} // 변경 시 state 업데이트
      />
      <p>입력된 값: {text}</p>
    </div>
  );
}

2️⃣ Uncontrolled Component (비제어 컴포넌트)

input 초기값을 defaultValue로 설정하고,
폼 요소의 값을 useRef로 사용해 DOM에 직접 접근하여 값을 가져오는 방식이다.
값을 React가 관리하지 않고, 값의 변경을 계속 관찰하지 않는다.
장점 : 상태를 따로 관리하지 않아도 되므로, 리렌더링으로 인한 성능 문제 발생하지 않는다.
단점 : React와 DOM 간의 동기화가 번거로워 값을 추적하기 어렵다.

import { useRef } from 'react';

function UncontrolledInput() {
  const inputRef = useRef(null); // useRef로 input 요소 참조

  const handleClick = () => {
    console.log(inputRef.current.value); // input값을 직접 DOM에서 가져온다!
  };

  return (
    <div>
      <input type="text" ref={inputRef} defaultValue="초기값" />
      <button onClick={handleClick}>값 출력</button>
    </div>
  );
}

✅ 각각 언제 사용해야 할까?

1️⃣ Controlled Component를 사용해야 하는 경우

입력값을 실시간으로 관리하고 싶을때 (ex. 검색창, 실시간 폼 입력).
React 상태를 기반으로 동작하는 UI가 필요할 때 (ex. 입력값을 기반으로 다른 UI 변경).
동일한 입력값을 다른 컴포넌트에서도 사용해야 할 때.

2️⃣ Uncontrolled Component를 사용해야 하는 경우

성능이 중요해서 state 업데이트를 최소화하고 싶을 때.
입력값 변경이 자주 발생하지 않을때
폼 데이터를 즉각적으로 저장할 필요가 없을 때
사용자가 입력한 값을 한 번만 가져오면 되는 경우 (ex. 폼 제출 시).
외부 라이브러리와의 호환성이 필요할 때 (ex. jQuery, D3.js 등과 함께 사용할 경우).

“react-hook-form”는 uncontrolled component 기반의 라이브러리다!

react-hook-form 사이트에서, uncontrolled 기반인 폼과, controlled인 폼을 비교해볼 수 있다.

controlled 컴포넌트는 input창 입력시마다 리렌더링되지만 uncontrolled는 그렇지 않다.

폼 구현시 흔히 써왔던 react-hook-form에 이런 내용이 있는줄은 몰랐다.

input요소 하나 입력시 폼 전체의 input요소가 리렌더링 되지 않는 것이 uncontrolled 컴포넌트 방식이기 때문이라니!

이걸 몰랐다면 나는 그냥 라이브러리가 알아서 잘 구현됐다보다 라고 생각하고 편하게 쓰기만 했을것이다.

defaultValue도 단순히 초기값을 위한게 아니라는 것을 알게되어 유익한 시간이였다!

requestAnimationFrame를 활용해 애니메이션 최적화 해보자

journey-dev — Sun, 2 Feb 2025 22:17:29 +0900

1. requestAnimationFrame (RAF)란?

RequestAnimationFrame 은 브라우저 내장 API이다.

브라우저 렌더링 주기(보통 60FPS)에 맞춰 콜백을 실행한다.

애니메이션을 부드럽게 실행하도록 도와주고, 프레임을 브라우저가 최적화하여 처리한다.

때문에 애니메이션 구현시, setInterval 대신 requestAnimationFrame을 더 많이 활용한다.

2. requestAnimationFrame 동작원리

애니메이션을 부드럽게 실행하기 위해

브라우저는 다음 렌더링 시점에 애니메이션을 예약하고 '매 프레임마다 자동으로 호출'한다.

브라우저의 리페인트 주기(60FPS) 에 맞춰 실행되는 것이다.

즉, 브라우저가 1초당 출력할 수 있는 프레임 수(fps) 기준으로 requestAnimationFrame(callback)을 사용하면,

그 프레임 간격마다 애니메이션이 반복 실행된다.

덕분에 애니메이션의 타이밍이 브라우저의 화면 갱신 주기와 정확히 일치하게 된다.

※ Frame 이란?
우리가 보는 영상이나 애니메이션은 정지된 이미지가 연속적으로 빠르게 바뀌는 것이다.
이 낱장의 정지된 이미지 하나를 프레임(Frame) 이라고 한다.

※ fps란? (Frames Per Second)
초당 프레임 수를 의미하며, 60fps는 1초 동안 60장의 화면을 그린다는 뜻이다.
일반적인 브라우저는 60FPS(1초당 60번 갱신) 을 목표로 한다.
1프레임 간격은 약 16.67ms(1초 ÷ 60) 이다.

3. requestAnimationFrame (RAF)와 태스크 큐

자바스크립트는 싱글스레드인로 동작하지만, 비동기 실행을 위해 이벤트 루프가 브라우저에서 실행된다.

비동기 실행을 위한 콜백함수들은 태스크 큐에 대기하며,

이후 콜스택에 아무런 태스크가 없으면 이벤트 루프에 의해 태스트 큐에 등록된 작업을 하나씩 가져와 나중에 실행하게 된다.

태스크 큐엔 1.마이크로 태스크 큐 2.매크로 태스크 큐가 있다.

그런데 requestAnimationFrame가 이 두 태스크 큐 사이에 위치한다는 것을 알게되었다.

✅ 태스크 큐의 작업 순서

1. 마이크로 태스트 큐 : Promise 후속처리 메서드 콜백함수

2. requestAnimationFrame : requestAnimationFrame 처럼 브라우저 렌더링 관련된 콜백함수

3. 매크로 태스크 큐 : setTimeout 등 그 외 나머지 비동기 콜백함수

 console.log("Start"); // 1

// 마이크로 태스크: Promise
Promise.resolve().then(() => {
  console.log("Microtask 1: Promise then"); // 3
}).then(() => {
  console.log("Microtask 2: Chained Promise then"); // 4
});

// 애니메이션 프레임: requestAnimationFrame
requestAnimationFrame(() => {
  console.log("Animation Frame: requestAnimationFrame callback"); // 5
});

// 매크로 태스크: setTimeout
setTimeout(() => {
  console.log("Macrotask: setTimeout callback"); // 6
}, 0);

console.log("End"); // 2

4. requestAnimationFrame 사용

requestAnimationFrame(callback);

callback : 다음 프레임이 렌더링될 때 실행할 함수. 리페인트 될 때 호출된다.
반환값 : 고유한 id를 반환한다.
이 값을 window.cancelAnimationFrame(id) 에 전달해 애니메이션을 취소할 수 있다.

✅ 사용코드 예제

requestAnimationFrame()은 한 번만 실행되므로 반복하려면 재귀적으로 호출해야 한다.

let rafY = 0;
let rafId

// 일정한 간격으로 애니메이션 발생
 function animateRAF(timestamp) { 
    rafY += 2; 
    rafBox.style.transform = `translateY(${rafY}px)`;
    rafId = requestAnimationFrame(animateRAF);
  }
  
document.getElementById('start').addEventListener('click', () => {
	  rafId = requestAnimationFrame(animateRAF); // 애니메이션 발생
});

document.getElementById('stop').addEventListener('click', () => {
	  cancelAnimationFrame(rafId); // 애니메이션 취소
});

✅ 활용

CSS 애니메이션 대신 JavaScript 으로 애니메이션 구현시

Canvas 에서 애니메이션 구현시 자주쓰인다. (ex. Canvas , WebGL 렌더링)
부드러운 스크롤 효과 (ex. Parallax, Scroll Animation)

5. 왜 setInterval 대신 requestAnimationFrame을 써야 하나? (RAF 특징)

✅ 실행 주기

1. setInterval은
고정된 시간 간격(setInterval(()⇒{}, 16ms))으로 코드를 실행하게 된다.

2. requestAnimationFrame은
브라우저의 화면 프레임 주기(일반적으로 60FPS, 약 16.67ms)에 맞춰 실행된다. 브라우저의 리프레시 속도에 맞춰 실행되는 것이다.

→ 이로 인해 프레임 손실 없이 더 부드러운 애니메이션을 만들 수 있다.

✅ 리소스 효율성

1. setInterval은 불필요한 CPU 사용을 초래할 수 있다.

탭이 비활성화되거나, 창이 최소화 되었을 때도 계속 실행된다.

이렇게 백그라운드에서도 계속 실행되므로 특히 모바일에서의 성능 저하 문제가 있다.

2. requestAnimationFrame은 비활성화된 상태에서는 자동으로 멈추게된다.
→ 불필요한 연산을 줄여 CPU 사용을 절약할 수 있다. (리소스 낭비 방지)

✅ 타이밍 정확도

1. setInterval은 타이밍이 정확하지 않다.

setInterval(()⇒{} , 16ms) 는 사실 고정된 시간 간격(16ms)로 정확히 실행되지 않는다.

왜냐면, 자바스크립트는 싱글 스레드 기반이기 때문에 동기 작업이 다 끝나야 비동기 코드가 실행된다.

이때 CPU사용량이 많아지거나, 작업에 부하가 있다면 setInterval의 콜백은 16ms보다 더 대기하게 되서 늦게 실행될 수 있기 때문이다.

→ 때문에 프레임 간 간격이 불규칙해져 애니메이션이 끊기는 현상이 발생한다!

2. requestAnimationFrame은 브라우저 렌더링 사이클과 정확히 동기화되서 프레임 간 일관성이 유지된다.

브라우저 리페인트 주기(60FPS, 약16.67ms)마다 requestAnimationFrame의 callback이 자동으로 실행된다.
CPU가 부하가 많더라도, 브라우저가 알아서 조정해서 다음 프레임을 실행할 타이밍을 맞추게된다.

→ 때문에 프레임 간 간격이 균일해서 애니메이션이 부드럽게 실행된다!

6. 구현예제 - setInterval VS requestAnimationFrame

실제로 구현을 해보면 그 차이를 느낄 수 있다.

requestAnimationFrame은 일정한 속도로 부드럽게 이동하지만, setInterval은 확연히 끊기는 것을 볼 수 있다.

지금은 간단한 예시지만, 좀 더 복잡한 인터렉션이 발생하고 CPU에 부하가 높아지면 setInterval 은 확연히 더 느려질 것이다.

타입스크립트의 필요성에 대해

journey-dev — Sun, 5 Jan 2025 21:41:51 +0900

✅ 들어가며

취업 준비 시절, 나는 타입스크립트까지 제대로 공부하지 못한 채 취업에 성공했다.
당시에는 타입스크립트가 프론트엔드 개발을 더 안정적이고 확실하게 만들어주는 도구라는 정도로만 알고 있었다.

그러나 현업에서 자바스크립트로 개발을 하면서, 타입스크립트의 필요성을 몸소 체감하는 순간이 많았다.

함수의 파라미터는 숫자형이어야 했지만, 라이브러리 반환값은 문자열인 숫자로 반환되는 바람에 오류가 발생한 적이 있다.

이 오류의 원인을 파악하는 데 시간이 꽤 걸렸던 기억이 난다.

또한, 개발 완료 후 코드를 실행했을 때 콘솔에 런타임 에러가 발생하곤 했고, 그 에러를 해결하는 데 많은 시간을 쏟았다.
만약 처음부터 타입 가드를 적용해 undefined.length 같은 상황을 처리했다면,
TypeError: Cannot read property of undefined 이런 런타임 오류가 발생하는 문제를 예방할 수 있었을 것이다.

현재 나는 타입스크립트를 잘 활용하기 위해 TypeScript Challenge를 풀며 하나씩 학습을 이어가고 있다.
타입스크립트가 가져다주는 이점을 더 깊이 이해하고, 이를 통해 더 안정적이고 효율적인 코드를 작성하고자 한다.

✅ TypeScript와 Javascript

TypeScript는 JavaScript의 Superset(상위 확장)이다.
기존 JavaScript 코드를 그대로 사용하면서, JavaScript에 정적 타입 시스템을 덧붙여 개발자 경험을 향상시킨 것이다.

인터프리터와 컴파일러

일단 ts와 js의 차이를 알기 위한 배경지식으로 "인터프리터와 컴파일러"를 이해해야 한다.

구분	인터프리터	컴파일러
작동 방식	명령어 단위로 번역하며 즉시 실행	전체 코드를 한 번에 번역 후 실행
오류 발견 시점	실행 중 (런타임)	컴파일 시 (실행 전)
장점	- 코드 수정 후 즉시 실행 가능 - 빠른 피드백 가능	- 실행 속도가 빠름 - 사전 오류 검출 가능
단점	- 실행 속도가 느림 - 런타임 오류 발생 가능	- 초기 컴파일 시간 소요 - 잦은 수정 시 비효율적
대표 언어	JavaScript, Python 등	TypeScript, C, Java 등

인터프리터 (Interpreter)

소스 코드를 한 줄씩 읽어 즉시 실행하는 방식
컴파일러와 달리 전체 코드를 한번에 번역하지 않고, 소스코드 명령어 한줄마다 기계어로 번역하여 바로 실행되는 것이다.
장점 : 번역과 실행이 동시에 이뤄져 즉각적인 결과 확인 가능 (실행 즉시 번역됨)(잦은 코드 수정시 유리함).
단점1 : 한번에 한 문장씩 번역후 실행시키기 때문에 실행 속도가 느리다.
단점2 : 코드 실행 중에만 오류를 발견할 수 있음.

컴파일러 (Compiler)

소스 코드를 한 번에 스캔해 기계어로 변환(번역)한 실행 파일을 생성하는 방식
변환(컴파일) 단계에서 문법,타입 오류 확인하며 변환된 파일이 실행된다.
장점1 : 실행 전에 모든 오류 검출 (코드 컴파일 하는 과정에서 오류 발생하게된다),
장점2 : 빠른 실행 속도 (처음에 한번에 기계어로 컴파일 해놔서 실행이 빠르다)
단점: 초기 번역 시간이 길고 잦은 수정에 비효율적.

(참조 : 컴파일러(compiler)와 인터프리터(interpreter)의 차이)

인터프리터 언어 vs 컴파일러 언어

1. JavaScript (인터프리터 언어)

JavaScript는 인터프리터 방식으로 실행되기 때문에, 코드를 실행하는 과정에서 오류를 발견한다.

이런 방식은 코드 실행 전에 오류를 사전에 방지하기 어렵다.

2. TypeScript (컴파일 언어)

TypeScript는 컴파일러를 통해 JavaScript로 변환되기 전에 코드의 문법과 타입을 검증한다.

컴파일 단계에서 오류를 미리 발견하므로, 런타임에서 발생할 수 있는 문제를 줄일 수 있게된다.

동적 타입 언어 vs 정적 타입 언어

1. JavaScript (동적 타입 언어)
1) 타입 결정 시점 : 런타임시. 변수에 어떤 데이터가 들어갈지는 실행 중에 확인된다.

2) 안정성 : 낮음 (런타임 오류 가능)
개발 단계에서 오류를 확인하기 어렵다.

프로그램 실행 중에야 오류를 발견할 수 있어 사용자에게 영향을 미칠 수 있습니다.

3) 타입 변경 : 코드 실행시 자유로운 타입 변경 허용

function sum(a, b) {
  return a + b;
}
sum(1, 2);       // 3
sum("x", "y");   // 'xy' (문자열 결합)

2. TypeScript (정적 타입 언어)

1) 타입 결정 시점 : 컴파일시. 변수의 타입이 런타임 이전의 컴파일 단계에서 결정된다.

2) 안정성 : 높은 (컴파일시 오류 검출)

3) 타입 변경 : 타입 변경시 오류 발생

function sum(a: number, b: number): number {
  return a + b;
}
sum("x", "y");
// error TS2345: Argument of type '"x"' is not assignable to parameter of type 'number'.
// 컴파일 에러: 'string' 타입은 'number' 타입에 할당할 수 없음

✅ TypeScript를 사용하는 이유

1. 런타임 에러 감소로 안정성 강화

JavaScript는 동적 타입 언어로, 실행 중 오류가 발생할 가능성이 크다.
이로인해 사용자에게 그 오류가 그대로 노출될 위험이 있다.

function greetUser(userName) {
  console.log("Hello, " + userName.toUpperCase() + "!");
}

// 올바른 호출
greetUser("Alice"); // 출력: Hello, ALICE!

// 잘못된 호출 - userName에 undefined가 전달됨
greetUser(); // 런타임 오류 발생: TypeError: Cannot read properties of undefined (reading 'toUpperCase')

// 잘못된 호출 - userName에 숫자가 전달됨
greetUser(123); // 런타임 오류 발생: TypeError: userName.toUpperCase is not a function

반면, TypeScript는 컴파일 단계에서 오류를 발견해 실행 전 수정할 수 있다.

function add(a: number, b: number): number {
  return a + b;
}

add(10, "20"); // 컴파일 에러 발생: '20'은 string 타입

2. 개발자 경험(DX) 향상

TypeScript는 IDE의 자동완성, 타입 추론, 코드 탐색 기능을 강화하여 개발 생산성을 높인다.

이를 통해 파라미터의 형태나 타입을 vscode에서 즉시 확인할 수 있어 코드 작성 속도가 빨라진다.

나는 이 점이 개발하면서 정말 편했던 것 같다.

const user = {
  name: "Alice",
  age: 25,
};

console.log(user.); // 자동완성을 통해 'name'과 'age'를 빠르게 확인 가능

3. 유지보수성 증가

- 타입을 명확히 선언하여, 의도치 않게 타입을 변경하는 문제를 방지할 수 있다.

- 디버깅을 수월하게 할 수 있다 : 개발시 vscode에서 오류를 바로 알려주기 떄문에 문제를 빠르게 파악할 수 있다.

- 협업시 인터페이스를 정의하는데 도움이 되기도 한다.

interface User {
  id: number;
  name: string;
  email?: string; // 선택적 속성
}

function createUser(user: User): void {
  console.log(user);
}

createUser({ id: 1, name: "John" }); // 올바른 호출
createUser({ id: 2 }); // 컴파일 에러 발생: 'name' 속성 누락
createUser({ id: "3" }); // 컴파일 에러 발생: 'string' 형식은 'number' 형식에 할당할 수 없습니다.

✅ 타입스크립트 컴파일러 동작원리

npx tsc note.ts를 실행하면 note.ts 파일이 note.js로 변환이 된다.
단순히 명령어 만 실행할 줄 알았는데 이게 어떤 원리로 인해 발생하는건지 알아보자!

TypeScript의 컴파일러(tsc)는 고급 프로그래밍 언어인 TypeScript 코드를 브라우저나 Node.js에서 실행 가능한 JavaScript 코드로 변환하는 역할을 한다. 이 과정은 크게 4단계로 이루어진다.

1. 파일 로드 및 파싱

TypeScript 컴파일러는 프로젝트의 설정 파일(tsconfig.json)을 읽어들인 뒤, 컴파일 대상 파일을 식별한다.
그런 다음, TypeScript 파일(.ts, .tsx)을 로드하고 각 파일을 파싱하여 추상 구문 트리(AST, Abstract Syntax Tree)를 생성한다.

우리가 작성한 코드는 컴파일러에게는 단순한 텍스트에 불과하기 때문에 AST로 파싱하는 것이다.

AST는 우리가 작성한 코드를 컴파일러가 이해할 수 있는 형태로 구조화한 트리이다.

AST는 이후 과정에서 타입 검사 및 변환 작업에 활용된다.

// 1. typescript코드
const add = (a: number, b: number): number => {
  return a + b;
};

// 2. 위 코드를 컴파일러가 읽으면, 다음과 같은 AST를 생성한다.
Program
├── VariableDeclaration
│   ├── Identifier: "add"
│   ├── ArrowFunctionExpression
│       ├── Parameters
│       │   ├── Identifier: "a" (type: number)
│       │   ├── Identifier: "b" (type: number)
│       ├── ReturnType: number
│       ├── Body
│           ├── ReturnStatement
│               ├── BinaryExpression
│                   ├── Identifier: "a"
│                   ├── Operator: "+"
│                   ├── Identifier: "b"

2. 타입 검사

TypeScript의 핵심 기능인 정적 타입 검사가 이 단계에서 이루어진다.

컴파일러는 생성된 AST를 기반으로 각 변수, 함수, 객체 등의 타입을 확인하게 된다.

- 타입 오류가 발견되면 컴파일을 중단하고 해당 오류를 보고한다.

3. js코드 생성

타입 검사가 완료된 후, TypeScript 컴파일러는 AST를 변환하여 JavaScript 코드로 출력한다.
TypeScript 코드에서 작성한 타입 정보는 JavaScript 코드에는 포함되지 않고, 실행 가능한 순수 JavaScript 코드만 생성된다.

- 컴파일러 옵션(target)에 따라 출력되는 JavaScript 코드의 표준(ES5, ES6 등)이 결정된다.

// tsconfig.json
{"target": "es2016", ...}

4. 출력과 번들링

(참고 : https://develog-yeon.tistory.com/35)

✅ 결론

타입스크립트를 사용해보니, “한 번 써보면 다시는 안 쓸 수 없다”는 말이 뭔지 확 와닿았다.

지난 ts없이 개발하던 회사 프로젝트에서는 변수의 타입이 확실치 않아 불안감이 있었다.

혹여 라이브러리가 숫자를 문자열로 응답하지는 않을까 싶어 typeof로 확인해야 했고,

또 데이터 값이 undefined일 때 가드 처리를 빼먹지는 않았을까 하는 걱정이 항상 따라다녔다.

하지만 타입스크립트를 사용하면서 이런 고민이 크게 해소되었다.

타입이 명확화되있다 보니 어떤 값이 들어와야 하는지 예측이 가능해졌고,

또한 런타임 에러를 미리 방지하며 개발을 한다는 점에 안도감도 들었다.

타입스크립트를 사용하지 않았던 과거의 경험 덕분에, 지금은 TS의 필요성과 강력함을 더욱 체감하고 있다.

Custom React 구현하기

journey-dev — Sun, 22 Dec 2024 18:09:09 +0900

리액트의 내부 동작을 깊이 이해하기 위해 직접 리액트를 구현해보는 튜토리얼을 진행했다.

지금보면 코드가 눈에 다 들어와서 별로 복잡해보이진 않지만, 처음에는 코드를 이해하는게 힘들었다.

링크드 리스트처럼 노드마다 부모, 자식, 형제로 얼키설키 엮여 있는 구조와

Fiber 노드 객체의 속성과 뎁스가 너무 많아 코드를 파악하기 어려웠다.

이런 문제를 해결하기 위해 각 노드 객체의 관계를 그림으로 직접 그려보며 구조를 하나씩 이해해나갔다.

거의 그림 그리면서 코드 파악했다

튜토리얼 사이트

전체코드

튜토리얼을 통해 파악한 주요 개념들을 정리해보았다.

1. Fiber란?

1) 정의

Fiber는 각 DOM 노드(element)마다 생성되는 객체로, Fiber Tree를 구성하는 작업 단위이다.

Fiber Tree는 렌더링 프로세스를 관리하기 위한 구조인데,
이를 기반으로 react는 DOM Tree를 업데이트를 효율적으로 관리하고 최적화한다.

Fiber로 작업 단위를 나누는 이유는?

아래에 설명할 동시성 렌더링(Concurrent Rendering)을 하기 위해서다.
Fiber Tree 생성 작업을 한 번에 처리하지 않고, 우선순위가 높은 작업이 있다면 Fiber 생성을 중단 했다가
다시 idle 상태에서 이어서 처리하기 위해서이다.

2) Fiber의 구조

const fiber = {
  type: "div",
  props: {
    id: "root",
    className: "container",
    children: [],
  },
  parent: null,
  sibling: null,
  child: null,
  dom: null,
  alternate: null,
  effectTag: "" 
};

3) Fiber Tree 예제

function App() {
  return (
    <div>
      <h1>
        <p>p</p>
        <a>a</a>
      </h1>
      <h2></h2>
    </div>
  );
}

const container = document.getElementById("root");
const element = <App />;

Didact.render(element, container);

위 코드의 Fiber Tree는 아래와 같이 구성된다.

h1 노드의 fiber를 출력해보면 실제 이런식으로 구성되어있다.

h1 노드의 Fiber는 부모, 자식, 형제 관계가 객체 형태로 모두 연결되있다.

2. 동시성 렌더링 (Concurrent Rendering)

1) 정의

동시성 렌더링은 Fiber 조작(생성, 삭제, 수정)을 한 번에 처리하지 않고, idle 상태에서 작업을 나누어 처리하며
우선순위가 높은 작업이 즉시 처리되도록 설계된 React 렌더링 모델이다.
이를 통해 더 중요한 작업(ex: 사용자 인터랙션)을 우선 처리하여 사용자 경험을 개선할 수 있다.

(React 18 버전부터 도입된 기능)

2) 특징

작업 단위 쪼개기: Fiber Tree를 만드는 과정을 나누어 처리한다. 그 나눈 작업 단위를 Fiber 라고 한다.
Idle 상태 활용: Fiber 조작 과정은 idle 상태(유휴 상태)일 때 진행된다.
작업 우선순위 설정: 더 중요한 작업(예: 사용자 입력)은 우선 처리한다. (이땐 idle 상태가 아니게됨)

3) 필요성

동시성 렌더링이 없으면?
fber 생성 과정이 중단되지 않고 한번에 진행된다.
그래서 도중 사용자 인터렉션이 발생한면 사용자 인터렉션 작업은 뒤로 밀리게된다.
→ 결과적으로 사용자 경험이 저하된다.

동시성 렌더링이 있으면?
fber 생성 작업이 나뉘어 idle 상태에서 처리되므로, 사용자 입력과 같은 우선순위가 높은 작업이 즉시 처리된다.
→ 결과적으로 사용자 경험이 개선된다.

4) 구현

튜토리얼에서는 window.requestIdleCallback을 사용해 idle 상태를 감지하고, 이 상태에서 Fiber 생성 작업을 진행했다.

그러나 이는 학습을 위한 구현이고, 실제 React는 자체적으로 스케줄링 알고리즘을 구현했다. (React 코드 참고)
React는 Scheduler 패키지를 사용하여 우선순위와 작업 시간을 관리한다.

(requestIdleCallback는 사파리에서 지원하지 않는다고 한다.)

3. Commit 단계

커밋 단계에서는 생성된 Fiber Tree를 기반으로 DOM Tree에 최종 렌더링 작업 실행한다.

Fiber 속성인 effectTag를 통해 DOM 노드의 생성, 수정, 삭제를 결정한다. 이 작업은 한 번에 처리된다.

4. 재조정 (Reconciliation)

1) 정의

재조정은 리렌더링시, 가상 DOM과 실제 DOM을 비교하여 변경된 부분만 업데이트하는 과정이다.
이를 통해 불필요한 DOM 업데이트를 줄이고 성능을 최적화할 수 있다.

2) 구현

이전 Fiber와 비교하여 변경된 부분만 새롭게 생성된 Fiber로 대체합니다.
Fiber Tree를 새로 구성한 뒤
똑같이 Commit 단계에서 변경된 부분만 실제 DOM에 반영하게 된다.

<마치며>

리액트의 내부 구현 원리를 이렇게 딥하게 파악한건 처음이다.

여태까지 나는 누군가 잘 정리해논 포스팅 글을 보며 공부하곤 했는데

직접 이렇게 코드를 파보고 짜보면서 이해하니, 더 체감되는게 크게 느껴진다.

Deep Dive라는게 이런거구나 라는 생각도 든다.

참조사이트

리액트 동시성이란?

React Fiber

React Fiber Tree

생각보다 더 섬세한 리액트 렌더링 과정

Render-and-commit

render-and-commit2

동기 VS 비동기, Promise와 async/await

journey-dev — Sun, 24 Nov 2024 17:34:55 +0900

요즘 JS코어를 다시 공부 하고있다.

여렴풋이 기억하고 있었던 내용을 다시 확실하게 잡아보고자 한다.

비동기에 대해 싹 정리해보도고 익히도록 해보자!

✅ 동기 , 비동기

동기

자바스크립트는 “싱글 스레드” 방식이기 때문에, 한번에 하나의 태스크만 처리할 수 있다.
이렇게 하나의 작업이 끝날 때까지 다음 작업이 대기하는 방식이 동기 처리이다.

// taskOne의 처리가 끝나기 전 까진 taskTwo는 대기하게 된다. 
function taskOne() {
  for (let i = 0; i < 1000000000; i++) {} // 시간이 걸리는 작업
  console.log("taskOne");
}

function taskTwo() {
  console.log("tasktwo");
}

taskOne();
taskTwo();

비동기

하지만 현재 실행 중인 작업이 종료되지 않은 상태라도, 다음 작업을 곧바로 실행할 수 있다.
이것이 비동기 처리.

비동기 처리 요청을 보낸 후 응답 여부와 상관없이 다음 태스크를 병렬적으로 수행할 수 있는 방식이다.
이 방식은 http 요청, 타이머 설정, 이벤트 핸들러 등 시간이 오래 걸리는 작업을 처리할 때 유용하다.

// taskOne을 먼저 호출했지만 setTimeout은 taskTwo가 실행된 이후에 실행된다.
// 비동기 콜백 함수(setTimeout)는 작업이 바로 완료되지 않고, 이후에 실행될 수 있다.
function taskOne() {
  setTimeout(() => { 
    console.log("taskOne");
  }, 1000);
}

function taskTwo() {
  console.log("tasktwo");
}

taskOne();
taskTwo();

✅ 비동기 처리는 어떻게 가능한 것인가?

이런 비동기 처리는 브라우저에서 실행되는 1)이벤트 루프와 2)태스크 큐를 통해 가능하다.

비동기 함수는 바로 실행되는게 아니라 먼저 태스크 큐에 등록된다.

이후, 이벤트 루프가 콜 스택에 실행 중인 작업이 없음을 감지하면, 큐에 있는 작업을 콜 스택으로 이동시킨다.
그제서야 비동기 함수가 실행되는 것이다.

이게 무슨 말인지 아래의 그림의 코드를 예로 자세히 설명해보겠다.
(※ 그림 출처)

1. 자바스크립트 엔진 구성 : Heap과 Call Stack
Heap

동적으로 생성된 객체들이 저장되는 메모리 영역
call stack에서 함수가 실행될 때, 실행 중 필요한 객체는 Heap에서 참조하게 되는 것이다.

Call Stack

함수 호출이 쌓이고 제거되는 곳. (실행 컨텍스트 스택)
함수가 실행될 때 Call Stack에 쌓이고, 실행이 완료되면 Call Stack에서 제거된다.
자바스크립트는 싱글 스레드로 동작하므로 한 번에 하나의 작업만 이 스택에서 실행되는 것이다.

2. Call Stack에서 함수 실행

greet() 함수 호출하면 → greet함수가 Call Stack에 들어와 실행 → 실행 완료 후 → Call Stack에서 제거된다.
이후, respond() 함수 호출되면 → Call Stack에 들어와 실행 → setTimeout이 실행된다.

3. Web API로 비동기 작업 위임

setTimeout은 브라우저에서 제공하는 Web API로 타이머 작업을 백그라운드에서 처리하도록 넘겨진다.
여기서 타이머(1000ms)가 완료될 때까지 Call Stack은 중단되지 않고, 그 사이에 다른 작업들을 계속 처리할 수 있다.

console.log("Start"); 

setTimeout(() => { 
	console.log("This is delayed"); // 비동기 콜백함수는 web api로 위임되고, 
}, 1000); 

console.log("End"); // 1000ms 후에 실행되는 비동기 작업을 기다리지 않고, 다음 작업을 바로 실행한다.

4. Queue에 작업 추가

타이머가 완료되면, setTimeout 콜백 함수(() => { return "Hey!" })가 Queue로 이동한다.

Queue는 두가지로 나뉜다.

마이크로 태스크 큐: 프로미스의 후속 처리 메서드(then, catch, finally)에 사용된 "콜백 함수"가 저장.
매크로 태스크 큐: setTimeout과 같은 타이머의 "콜백 함수"나 이벤트 핸들러가 저장됨.

5. Event Loop (이벤트 루프)

Queue는 이벤트 루프에 의해 관리된다.
이벤트 루프는 Call Stack이 비어 있는지 확인한다.
Call Stack이 비어 있으면, Queue에 있는 작업을 Call Stack으로 가져와 실행하게 된다.

6. 콜백 함수 실행

setTimeout의 콜백 함수가 Call Stack으로 이동해 실행된다.

✅ JS에서 비동기 처리 다루는 방식

1️⃣ 콜백 함수

비동기 작업에서의 콜백 함수란? : 비동기 작업이 완료되면 호출되는 함수

콜백 헬
비동기 작업을 순차적으로 처리하기 위해, 콜백 함수 안에 다음에 실행할 콜백함수를 넣게되는데
이렇게 콜백함수가 계속 중첩되면서 코드의 뎁스가 깊어져 코드가 복잡해지는 현상이다.

// script1로드 후에, script2 로드, script3 로드하는 비동기 작업 연결

loadScript('/my/script1.js', (script) => {
  loadScript('/my/script2.js', (script) => {
    loadScript('/my/script3.js', (script) => {
      // 세 스크립트 로딩이 끝난 후 실행됨
    });
  })
});

콜백 헬은 왜 문제되는가?

가독성 문제

뎁스가 깊어짐: 비동기 실행 이후로 후속 코드를 위해서는, 그 콜백 함수 내부에서 다 처리를 해야한다.
코드 흐름을 순차적으로 이해하기 어려움 : 중첩된 콜백 함수를 따라가며 읽어야 함

에러 처리의 어려움
동기 코드에서처럼 try-catch 문으로 에러 처리할 수 없다.

   try {
     setTimeout(() => {throw new Error("Error!");}, 1000);
   } catch (error) {
     console.error(error);
   }

setTimeout의 콜백함수가 실행될 시점에는, 이미 try{..}catch{..} 부분은 동기 실행으로 모두 실행이 종료된 상태다.
이후 비동기 실행만 덩그러니 실행되는 꼴이므로, 에러 객체는 catch로 받을 수 없게된다.

2️⃣ Promise

Promise란?

비동기 작업의 성공 또는 실패를 처리하고, 후속 작업을 체계적으로 연결할 수 있는 JavaScript의 내장 객체

콜백 헬 해결

Promise로 인해 비동기 작업이 여러개가 중첩되도 콜백 지옥 해결할 수 있게되었다.
코드의 깊이가 깊어지지 않는다.

Promise 객체

function myPromise() {
  return new Promise((resolve, reject) => {
      const data = fetch();

      if (data) {
        resolve(data);
      } else {
        reject("Error");
      }
  });
}

myPromise()
  .then((value) => {
    console.log("Success:", value); // "Success: data값"
  })
  .catch((error) => {
    console.error("Error:", error); // "Error: Error"
  })
  .finally(() => {
    console.log("Operation complete");
  });

Promise 생성자에는 executor라는 콜백 함수를 인자로 받는다.
그리고 executor 함수는 resolve 및 reject를 매개변수를 가진다.

resolve(value)

비동기 작업이 성공적으로 완료되었을 때 호출된다.
resolve의 매개변수 value는 성공시 전달할 값이다.
이 값은 .then() 메서드의 첫 번째 콜백함수로 전달되어 후속 작업에 사용된다.

reject(error)

비동기 작업이 실패했을 때 호출된다.
reject의 매개변수 error는 실패 시 전달할 값이다.
이 값은 .catch() 메서드의 첫 번째 콜백함수로 전달되어 에러 처리에 사용된다.

Promise 상태

1. pending (대기중)

Promise 객체는 resolve 또는 reject가 호출될 때까지 기다리게 된다.

이 상태에서는 then,catch가 실행되지 않는다.

2. fulfilled (성공)
resolve가 호출되면, Promise는 fulfilled(성공) 상태로 바뀌고, .then()에서 후속작업 처리

3. rejected (실패)
reject가 호출되면, Promise는 rejected(실패) 상태로 바뀌고, .catch()에서 후속작업 처리

Promise는 상태가 한 번 결정(settled)되면 더 이상 변경되지 않는다.
때문에 fulfilled, rejected 상태를 settled 상태라고도 표현한다.

후속 처리 메서드

1. then(onFulfilled, onRejected)

resolve로 반환된 값은 .then()의 첫 번째 콜백 함수의 매개변수로 전달된다.

프로미스 체이닝 : .then()은 새로운 Promise 객체를 반환한다. 때문에 또 then()을 이어서 프로미스 체이닝이 가능하다.

첫번째 인자 (onFulfilled)
: Promise가 수행될 때 호출되는 Function으로, 이행 값(fulfillment value) 하나를 인수로 받는다.
두번째 인자 (onRejected)
: Promise가 거부될 때 호출되는 Function으로, 거부 이유(rejection reason) 하나를 인수로 받는다.

2. catch
reject로 반환된 값은 .catch()의 첫 번째 콜백 함수의 매개변수로 전달된다.

프로미스 체이닝 : catch()는 새로운 Promise 객체를 반환한다. 때문에 또 then()을 이어서 프로미스 체이닝이 가능하다.

3. finally
resolve와 reject의 결과와 관계없이 항상 실행된다.
주로 로딩 스피너 제거와 같은 정리 작업에 사용된다.

myPromise()
.then((value) => console.log("Success:", value))
.catch((error) => console.error("Error:", error))
.finally(() => console.log("Cleanup complete"));

Promise 한계

then 메서드로 프로미스 체이닝하여 비동기 처리 흐름을 이어나갈 수 있지만,
then이 여러개 중첩되어 여전히 콜백 헬과 비슷한 문제 발생하게 된다.

fetch('https://example.com/api')
  .then(response => response.json())
  .then(data => fetch(`https://example.com/api/${data.id}`))
  .then(response => response.json())
  .then(data => fetch(`https://example.com/api/${data.id}/details`))
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error(error));

3️⃣ async-await

위의 promise체이닝의 한계를 해결하기 위해 async-await를 활용할 수 있다.

가독성 향상
: async-await을 사용하면 비동기 코드가 마치 동기 코드처럼 작성되어, 코드 흐름을 쉽게 이해할 수 있다.
: 각 비동기 작업을 기다리는 동안 코드가 일시 중지되고 순차적으로 실행되기 때문에 코드가 직관적이고 읽기 쉬워진다.
간단한 코드
: then, catch, finally 등의 후속 처리 메서드를 사용하지 않고도, 동기 실행 코드처럼 간결하게 작성할 수 있다.

// await를 통해 프로미스가 처리될 때까지 기다리며, 이후 코드를 순차적으로 실행하게 된다.

  async function getData() {
    const response = await fetch('https://example.com/api');
    const data = await response.json();
    const response2 = await fetch(`https://example.com/api/${data.id}`);
    const data2 = await response2.json();
    const response3 = await fetch(`https://example.com/api/${data.id}/details`);
    const data3 = await response3.json();
    console.log(data3);
  } 

  getData();

async await 사용법

async

1) 용도 : await를 사용하고자 하는 함수에 붙인다.

2) 반환값 : async 함수는 항상 Promise를 반환한다.

반환값이 있다면 자동으로 반환값이 resolve된 프로미스를 반환한다. (프로미스 안에 값이 resolve된 꼴)
반환값이 없으면 undefined를 resolve하는 프로미스를 반환한다.

async function example() {
return 42; // 자동으로 resolve된 Promise(42)를 반환
}

example().then(value => console.log(value)); // 출력: 42

await

1) 용도 : promise 작업이 settled (resolved, rejected) 될 때까지 다음 코드 실행을 일시 중지한다.

2) 사용 위치 : async함수 내부에, Promise 인스턴스 앞에 붙임.

3) 반환값

Promise가 resolved 상태일 경우, 프로미스가 resolve한 처리 “결과 값”만을 반환한다.
Promise가 rejected 되면, await는 에러를 throw 한다.

4) 순차적 실행 보장 : await를 활용하면 비동기 작업을 순차적으로 처리할 수 있다.

async function fetchTodo(){
    const res = await fetch("https://url"); // fetch는 프로미스를 반환. await를 통해 프로미스의 처리결과 값만 반환
    const todo = await res.json(); // json()도 프로미스를 반환. await를 통해 프로미스의 처리 결과 값만 반환
    console.log(todo)
}

async/await 에서의 에러처리

1. try…catch문 사용한 에러처리

try...catch를 사용하면 코드 블록 내에서 발생한 모든 예외를 catch에서 한 번에 처리 가능하다.

네트워크 에러와 다른 예외적인 상황(JSON 파싱 오류, 런타임 오류 등)을 모두 catch에서 처리할 수 있다.

async function fetchTodo() {
  try {
    const res = await fetch("https://url"); // http 에러
    const todo = await res.json(); // 런타임 에러
  } catch (err) {
    console.error("Error occurred:", err); // 모두 잡을 수 있음
  }
}

2. catch 메서드 사용한 에러처리
async 함수에서 try...catch 문을 사용하지 않으면, 예외가 발생할 경우 자동으로 rejected 상태의 프로미스가 반환된다.
따라서 then과 catch 메서드를 통해도 후속 처리가 가능하다.

const foo = async function fetchTodo() {
  const res = await fetch("https://url");
  const todo = await res.json();  
};

foo()
  .then(() => console.log("success"))
  .catch(() => console.log("err"));

참고 문서

https://www.lydiahallie.com/blog/event-loop

JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue

Learn how the browser event loop, task queue, microtask queue, and Web APIs work together to enable non-blocking, asynchronous JavaScript.

www.lydiahallie.com

https://www.lydiahallie.com/blog/promise-execution

JavaScript Visualized - Promise Execution

This guide covers some of the inner workings of Promises, exploring how they leverage concepts like the Microtask Queue and Event Loop to enable non-blocking async code. Follow along with easy-to-understand examples and visualizations.

www.lydiahallie.com

https://inpa.tistory.com/entry/JS- -자바스크립트-콜백-함수

https://inpa.tistory.com/entry/JS- -비동기처리-Promise

https://inpa.tistory.com/entry/JS- -비동기처리-async-await

React-Query 사용기

journey-dev — Sun, 20 Oct 2024 23:39:21 +0900

최근 사이드 프로젝트를 하면서 React-Query를 접하게 되었습니다.

도입한 이유는 사실 단순히 궁금해서였습니다.

많이들 사용하는 것 같던데 정작 저는 한번도 사용해보지 않아 그 이유가 궁금했습니다.

React-Query를 사용하며 배우고 느꼈던 것들을 정리해보겠습니다.

(주니어의 시각에서 작성한거라, 보완이 필요한 부분이 있을지도 모르겠습니다!? )

✅ React-Query란 ?

서버 상태 관리를 위한 라이브러리.

데이터 패칭, 동기화, 캐싱 등 기능을 제공해 개발자가 서버 데이터를 손쉽게 관리할 수 있다.

✅ 효용

효용1. 상태 관리의 단순화

1) React-Query 없이 관리할 땐

일반적으로 useEffect와 useState를 사용해 직접 서버 데이터를 저장하고,

loading과 error 상태는 클라이언트에서 관리해야 한다.

아래의 코드 예시처럼, 데이터 페칭시 관리해야 할 클라이언트 상태가 필요하게 되어 state 수도 많아진다.

const Component = () => {
  const [data, setData] = useState(null);  // 서버 데이터 저장
  const [loading, setLoading] = useState(false); // 로딩 상태 저장
  const [error, setError] = useState(null);  // 에러 상태 저장
 
  // 컴포넌트가 마운트될 때 처음 데이터 패칭
  useEffect(async() => {
    try {
      setLoading(true);  // 로딩 상태 활성화
      const response = await axios.get('/api/...');  
      setData(response.data);  // 데이터 저장
      setError(null);  // 에러 상태 초기화
    } catch (err) {
      setError(err);  // 에러 상태 저장
    } finally {
      setLoading(false);  // 로딩 상태 비활성화
    }
  }, []);  
  
  return <></>
};

2) React-Query를 사용하면

React Query는 비동기 통신에 필요한 상태(isError, error, isLoading 등..)을 내부적으로 관리해주기 때문에,

개발자가 별도로 클라이언트 상태를 직접 관리할 필요가 없어진다.

(※ useQuery return값 참고 )

<동일한 코드를 useQuery로 패칭하는 예제 코드>
코드가 현저히 감소함을 볼 수 있다

const fetchData = async () => {
  const { data } = await axios.get('/api/...');
  return data;
};

const Component = () => {
  const { data, error, isLoading, refetch } = useQuery('fetchData', fetchData);   // useQuery 훅을 사용하여 데이터 패칭

  return (<></>);
};

효용2. 서버 상태와 클라이언트 상태의 명확한 구분

뿐만 아니라 서버 상태와 클라이언트 상태를 명확히 구분할 수 있게된다.

React Query는 서버 상태만을 처리하고, 클라이언트 상태는 useState나 상태관리 라이브러리로 구분하여 관리할 수 있다.

이를 통해 UI관련된 상태값 정도만 클라이언트가 갖고 있게 된다.

효용3. key를 통한 데이터 업데이트

1) React-Query 미사용시 : 수동 데이터 관리

예로들면, 상품 상세 페이지에서 데이터를 수정하여 서버에 PUT요청을 보내 수정 완료되고 나면,

수정된 데이터를 새로 불러오기 위해 상품상세에 대한 GET 요청을 다시 실행해야 한다.

또한 상품 리스트 항목도 데이터 최신화를 위해 다시 GET요청을 보내야한다.

이렇게 데이터 최신화를 위해 연관된 데이터를 직접 수동으로 일일히 관리해줘야 한다.

2)React-Query를 사용시 : 자동 데이터 관리

React Query를 사용하면, 상품 상세 페이지 정보를 수정한 후 product와 관련된 쿼리 키를 무효화하기만 하면

관련된 모든 데이터 쿼리(get:상품 상세, getMany:상품 리스트)가 자동으로 다시 페칭된다.

데이터를 업데이트한 후 특정 쿼리 키를 무효화하여, 연관된 데이터들이 자동으로 다시 페칭되어 최신 상태로 유지되는 것이다.

이렇게 쿼리키만 잘 관리하면, 직접 데이터를 업데이트 하는 코드를 줄일 수 있다!

효용4. 캐싱 기능을 사용할 수 있다.

1) staleTime (기본값 0)

staleTime은 데이터를 얼마나 오래 "fresh" 한 상태로 유지할지에 대한 시간이다.

이 시간동안은 데이터가 fresh한 상태로 간주되서 네트워크 요청을 새로 하지 않고 캐싱된 데이터를 사용한다.

이 시간이 지나면 데이터는 "stale" 상태가 된다.

시간이 지난 후 화면 출력시, stale된 캐시 데이터를 일단 사용하여 화면에 출력해주고

이후 새로운 api호출을 통해 데이터를 refetch 시킨다.

이러한 캐싱 기능을 이용해

업데이트가 자주 필요 없는 데이터는 staleTime을 설정하여 해당 시간동안 네트워크 요청을 줄일 수 있게된다.

// 1. 쿼리 클라이언트에 설정
new QueryClient({
  defaultOptions: {
    queries: { 
       staleTime: 0 // 쿼리가 최신 상태에서 더 이상 최신이 아닌 상태로 전환하는 시간
    }
  }
})

// 2. api마다 각각 설정
// 유저 데이터 쿼리 (1분 동안 stale 상태로 유지)
  const { data: userData } = useQuery('user', fetchUserData, {
    staleTime: 60000, // 1분
  });

  // 상품 데이터 쿼리 (5분 동안 stale 상태로 유지)
  const { data: productData } = useQuery('products', fetchProductData, {
    staleTime: 300000, // 5분
  });

2) cachetime (gc time)

cachetime 은 데이터가 메모리에 유지될 시간을 의미한다.

1) staleTime은 설정 시간이 지나도 데이터를 삭제하지는 않고, stale된 데이터가 그대로 남아있는 반면

2) cachetime은 설정된 시간이 지나면, 메모리에서 데이터를 아예 삭제하게 된다.

그래서 화면에 일단 빈 데이터가 출력되고 > 쿼리를 사용되는 컴포넌트가 마운트되서 > 쿼리가 다시 사용될때 > api를 새로 호출하여 데이터 refetch 하게 된다.

// 예: 유저 데이터 쿼리 - 5분 동안 캐시에 유지
const { data: userData } = useQuery('user', fetchUserData, {
  staleTime: 60000, // 1분 동안 fresh
  cacheTime: 300000 // 5분 후 메모리에서 삭제
});

✅ 배운점

1. 쿼리 키 관리 관리의 중요성

리액트 쿼리를 사용하면서, 쿼리 키 관리가 중요하다는 것을 느꼈다.

쿼리 키를 어떻게 구조화하느냐에 따라 개발 효율이 크게 달라졌다.

쿼리 키 관리 방식이 코드의 일관성과 유지보수성에 큰 영향을 끼쳤다.

1️⃣ 문제

처음에는 쿼리 키를 직접 입력하는 방식으로 구현했다.

예를들어, 상품 목록 페이지를 구성할 때 페이지마다 쿼리 키를 일일히 지정해줬다.

직접 입력하다보니 규칙이 없어 쿼리 키 형식을 일관되게 유지하는 것이 어렵고,

프로젝트가 커지면 쿼리 키가 다양해지면서 유지보수 하기도 어려워진다.

// 상품 목록 
const { data } = useQuery(["product", "getMany", "1"], () => fetchProductList(1)); // 1페이지
const { data } = useQuery(["product", "getMany", "2"], () => fetchProductList(2)); // 2페이지
// 쿼리키 ["product", "getMany", "3,4,5..."]

// 상품 상세
const { data } = useQuery(["product", "get", "detailId1"];, () => fetchProductDetail("detailId1"));
const { data } = useQuery(["product", "get", "detailId2"];, () => fetchProductDetail("detailId2"));
// 쿼리키 ["product", "get", "detailId3,4,5,.."]

2️⃣ 해결 - Query Key 팩토리 함수 사용

Query Key 팩토리 함수를 사용하면 위 문제를 해결할 수 있다. (※ Query Key 팩토리 함수 - 참고1, 참고2, 참고3)

팩토리 함수는 쿼리 키를 일관되게 생성해주는 함수로, 코드에서 일관된 쿼리키 형태를 유지 할 수 있게 해준다.

덕분에 쿼리 키 입력을 일일히 직접 관리하는게 아닌, 자동화 하여 유지보수성을 높일 수 있었다.

<코드 예제>

아래의 코드에서 ProductQuery는 쿼리 키를 생성하는 팩토리 역할을 한다.
"getMany와 get" 메서드를 통해 "상품 목록과 상품 상세"의 쿼리 키를 일관성 있게 관리할 수 있게 되었다.
prodQuery나 id를 인수로 전달해 유연하게 쿼리 키를 생성할 수 있어, 이후에도 동일한 패턴으로 관리할 수 있다.

<쿼리키 결과>

: 팩토리를 통해 생성된 쿼리 키는 다음과 같이 구조화되어 있다.

// 상품 목록 쿼리키
["product","getMany",{"include":2,"page":1,"size":3,"sort":"-createdAt"}]
["product","getMany",{"include":2,"page":2,"size":3,"sort":"-createdAt"}]

// 상품 상세 쿼리키
["product","get","66d429ff444bc2d5e2334aee"]
["product","get","66d42a06444bc2d5e2334afa"]
["product","get","66d42fe8444bc2d5e2334bb0"]

2. 쿼리 키 무효화 관리

1️⃣ 문제

위에서 쿼리키를 수동으로 작성하고 관리하는 것이 비효율적이라고 했듯이,

쿼리키를 무효화 할 때도 일일히 처리하는 것은 좋지 않은 방법이라 생각됐다.

예를 들어, 상품 리스트 쿼리 키가 페이지별로 생성되는 구조에서

상품 리스트 3페이지에서 항목 하나를 삭제 한 후, 3 페이지 쿼리키를 removeQueries를 사용하여 직접 제거를 했더니

그럼 그 뒤에있는 4,5.. 페이지도 다시 refresh 시켜줘야 하는 상황이 생겼다.

이렇게 연관된 쿼리키를 수동으로 직접 관리하기 어렵다.

2️⃣ 해결

쿼리키를 관리 할때 범주를 잡아 쿼리키를 설정하고, 범위 중 하나가 업데이트되면 해당 범주 전체를 한번에 무효화 시켜버려야 한다.

client.invalidateQueries({ queryKey: ProductQuery.all })

const ProductQuery = {
  all: ["product"] as const,
  getMany: (prodQuery: ProductQueryParams) => [...ProductQuery.all, "getMany", prodQuery] as const,
  get: (id: string) => [...ProductQuery.all, "get", id] as const,
};

const CategoryQuery = {
  all: ["category"] as const,
  getMany: (categoryQuery: CateQueryParams) => [...CategoryQuery.all, "getMany", categoryQuery] as const,
  get: (id: string) => [...CategoryQuery.all, "get", id] as const,
};

상품(목록,상세) 관련 쿼리 키가 한 곳에서 집중되어 관리되어

상품 목록을 업데이트(추가,삭제,수정) 후 상품 관련 쿼리키를 한번에 invalidate 시킬 수 있다.

ProductQuery.all을 상품 관련된 쿼리키 생성 함수인 getMany, get에 공통으로 적용해주어

ProductQuery.all 만 invalid하면 연관된 getMany, get도 한번에 invalid 시킬 수 있다.

이렇게 그냥 쿼리 키만 잘 관리해주면 된다.

일일히 상품 목록 api를 다시 불러오고, 관련된 상품 상세 등 데이터를 수동으로 refetch 하지 않아도 된다.

✅ 느낀점

사용해보니 "이 좋은걸 왜 이제 알았을까" 하는 생각이 들었고, 아직 장점이 더 많은 것 같다고 생각된다.
그렇다면 무조건 이 기술을 사용하는게 좋은걸까?

아직 거기까진 모르겠다.

앞으로 사이드 프로젝트를 진행하며 좀 더 리액트 쿼리와 친해져보고싶다!

https://www.youtube.com/watch?v=MArE6Hy371c

#fake-store

FTP와 SFTP에 대해, RSA에 대해

journey-dev — Fri, 4 Oct 2024 00:13:36 +0900

ftp 자동배포를 시도하면서 알게된 것들에 대한 내용을 포스팅해보겠다.

누군가 FTP가 뭐에요?라고 묻는다면, 나는 "파일 전송 프로토콜"이요 라고 밖에 말하지 못하겠다.

이렇게 허접하게 말고, 좀 더 제대로 알고 싶다!

# FTP와 SFTP

FTP(File Transfer Protocol)

서버와 클라이언트 간에 파일을 전송하기 위한 네트워크 프로토콜

특징1. 전송방식

: 파일을 암호화하지 않은 상태로 전송함.
: 전송 데이터가 암호화되지 않고 평문으로 전송해되기 때문에 전송된 파일, 사용자이름, 비밀번호가 노출될 위험 있음. -> 보안 취약

특징2. 보안이 취약함

: 보안적으로 취약함. 그래서 실무에서는 대체로 사용하지 않는다.

SFTP(SSH File Transfer Protocol)

ftp 연결에 보안을 강화한 것

특징1. 전송방식
: 데이터가 암화화하여 전송되므로 파일뿐 아니라 인증 정보도 안전히 보호됨.

특징2. 보안 강화

특징	FTP	SFTP
보안	암호화X	암호화O (SSH 기반)
기본 포트	21	22
전송 방식	평문 전송	암호화하여 전송
인증 방식	사용자 이름, 비밀번호	사용자 이름, 비밀번호 or SSH 키
사용	보안이 필요없는 파일 전송시	보안이 중요한 파일 전송시

느낀점

사내에서 ftp 인증 방식으로 개발서버는 텍스트 비밀번호를, 스테이징 서버를 ssh키를 사용하고 있는데

왜 이렇게 따로 처리하는지 이해할 수 있게됐다.

개발서버는 사내에서만 접속 가능한 사내서버여서 이미 보안이 설정되있기 때문에 비밀번호로 하는것이고,

스테이징 서버는 aws를 사용하고 있어 보안을 강화하기 위해 ssh키를 사용한 것 이였다.

이런 배경지식을 갖고 보니 매일 하던 업무를 다른 방향에서 볼 수 있는 것 같다.

※ 참조 사이트

https://terms.naver.com/entry.naver?docId=3574148&cid=59088&categoryId=59096

https://inpa.tistory.com/entry/WEB-%F0%9F%97%84%EF%B8%8F-FTP-SFTP-%EB%9E%80

# rsa 암호화 및 디지털 서명

1. 암호화

rsa는 암호화 알고리즘 중 하나.

2개의 키(공개키 public key, 개인키 private key)를 이용한 비대칭 암호화다.

공개키로 데이터를 암호화하고, 개인키로 이를 복화하하는 방식으로 데이터를 보호한다.

오직 그 개인키를 가진 사람만 이를 해독할 수 있게되는 것이다.

2. 서명(디지털 서명)

개인키를 갖은 사람만이 공개키로 암호화된 것을 해독할 수 있으니, 해독을 했다면 신분이 인증되는 것이다.

특징

1. 보안이 뛰어남

2. 속도는 느림 : 대용량 데이터를 암호화하는 경우 속도가 느려짐

활용

1. SSH에서 사용자 인증시 사용

2. 전자 상거래, 공인인증서 등 신분 증명시

※ 참조 사이트
https://velog.io/@480/RSA-%EC%95%94%ED%98%B8%ED%99%94-3%EB%B6%84-%EB%A7%8C%EC%97%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

css scope, scope 무시하기

journey-dev — Sun, 22 Sep 2024 23:33:43 +0900

css scope

기본적으로 css는 전역으로 적용된다.

그러나 css scoping을 하면, 해당 컴포넌트 내에서만 한정적으로 적용할 수 있게 된다.

css 범위를 해당 컴포넌트로 제한하여, 컴포넌트간 스타일 충돌을 방지할 수 있다.

스코핑 결과

css scoping 적용하면 컴포넌트별로 랜덤한 접두사가 붙는다.

html 요소에는 고유한 랜덤 접두사가 추가되고, css에는 접두사가 포함된 셀렉터로 변환된다.
만약, 두 컴포넌트에서 동일한 클래스명을 쓰더라도 서로 다른 접두사가 추가되어 서로 충돌나지 않는다.

scope 예외

그러나 외부 UI라이브러리를 쓰다보면 scoping을 무시해야 할 때가 있다.

전역에서 하위 컴포넌트에 설정되있는 스타일을 직접 바꿔서 처리해야 하는 경우가 발생하곤 한다.

그럴 경우 vue에서는 ::v-deep 또는 :global 선택자를, vite에선 :global 선택자를 사용하여

css scoping을 무시할 수 있다.

스코핑 예외 처리 결과

.children은 이제 스코핑이 무시되어 랜덤한 접두사 같은것이 붙지 않고

그냥 순수 css처럼 되어 전역에 미치게 된다.

Vue (프레임워크)
: 뷰 프레임워크가 기본적으로 제공한다. vue-loader를 통해 css module 기능을 사용하게 된다.
React (라이브러리)
: vite 같은 번들러를 따로 설치해야 한다. vite에서 css module 기능을 제공해준다.

https://github.com/css-modules/css-modules/blob/master/docs/composition.md#exceptions

https://stackoverflow.com/questions/43613619/what-does-global-colon-global-do