OIL

[프레임워크 없는 프론트엔드 개발] - 3장. DOM 이벤트 관리

_OIL — Sat, 6 Jul 2024 21:41:52 +0900

YAGNI 원칙

YAGNI는 You Aren’t Gonna Need It의 약자로 “정말 필요하다고 간주할 때까지 기능을 추가하지 마라” 라는 원칙이다. 자신만의 아키텍처를 작성할 때 반드시 YAGNI 원칙을 적용해 당시에 직면한 문제만을 해결해야 한다.

DOM 이벤트 API

이벤트는 웹 애플리케이션에서 발생하는 동작이다. 전체 이벤트 리스트

마우스 이벤트 (클릭, 더블 클릭 등)
키보드 이벤트 (키다운, 키업 등)
뷰 이벤트 (뷰 리사이징, 스크롤 등)

을 포함한 사용자가 트리거한 이벤트에 반응 할 수 있다. 또한 네트워크의 상태나 DOM 콘텐츠의 변화에 따라 이벤트를 발생시킬 수 있습니다.

기본 클릭 이벤트 라이프사이클

속성에 핸들러 연결

on속성 이용 : onclick, ondblclick, onmouseover, onblur, onfocus 등

빠르지만 지저분한 방법
이 방법을 사용하면 한번에 하나의 핸들러만 연결할 수 있다. 즉 다른 코드가 onclick핸들러를 덮어 쓰면 원래 핸들러는 사라진다.

let button = document.querySelector("#button");
button.onclick = () => {
  console.log("Click 1");
};
button.onclick = () => {
  console.log("Click 2");
};

button = document.querySelector("#eventListener");
const firstHandler = () => {
  console.log("First handler");
};

const secondHandler = () => {
  console.log("Second handler");
};

button.addEventListener("click", firstHandler);
button.addEventListener("click", secondHandler);

window.setTimeout(() => {
  button.removeEventListener("click", firstHandler);
  button.removeEventListener("click", secondHandler);
  console.log("Removed Event Handlers");
}, 1000);

EventTarget가 모든 DOM 노드의 베이스에 있기때문에 모든 DOM 노드에서 '이벤트’를 사용할 수 있다.
addEventListener의 첫 번째 매개변수는 이벤트 타입이다.
두 번째 매개 변수는 콜백이며 이벤트가 트리거될 때 호출된다.
property메서드와 달리 addEventListener는 중복 이벤트 등록이 가능하다.
DOM에 요소가 더 이상 존재하지 않으면 메모리 누수를 방지하고자 이벤트 리스너도 삭제해야 한다. 이를 위해 removeEventListerner 메서드를 사용한다.

이벤트 객체

button = document.querySelector("#event");
button.addEventListener("click", (e) => {
  console.log("event", e);
});

addEventListener의 콜백에는 이벤트를 나타내는 매개변수를 포함할 수 있다.
이벤트 객체에는 포인터 좌표, 이벤트 타입, 이벤트를 트리거한 요소 같은 유용한 정보가 많이 들어있다.

DOM 이벤트 라이프사이클

addEventListener(type, listener, useCapture);

세 번째 매개변수는 useCapture라고 불리며 기본값은 false이다.
이 매개변수는 선택 사항이지만 브라우저 호환성을 얻으려면 포함시켜야한다.

<body>
	<div>
		this is a container
		<button>Click here</button>
	</div>
</body>

const button = document.querySelector('button')
const div = document.querySelector('div')

div.addEventListener('click', () => console.log('Div Clicked'), false)
button.addEventListener('click', () => console.log('Button Clicked', false)

버튼을 클릭하면 button이 div안에 있으므로 button부터 시작해 두개의 핸들러가 모두 호출된다. 즉, 이벤트 객체는 트리거한 DOM 노드(예제의 경우 button)에서 시작해 모든 조상 노드로 올라간다. 이러한 매커니즘을 이벤트 버블링 이라고 한다.

const button = document.querySelector("button");
const div = document.querySelector("div");

div.addEventListener("click", () => console.log("Div Clicked"), false);
button.addEventListener(
  "click",
  (e) => {
    e.stopPropagation();
    console.log("Button Clicked");
  },
  false
);

위 예제에서는 div 핸들러는 동작하지 않는다.
Event 인터페이스의 stopPropagation메서드를 사용해 버블 체인을 중지 할 수 있다.
이 기술은 복잡한 레이아웃에서 유용할 수 있지만 핸들러의 순서에 의존하는 경우 코드를 유지하기 어려울 수 있다. 이런 경우 3장 끝에서 나오는 이벤트 위임 패턴이 유용하다.

const button = document.querySelector('button')
const div = document.querySelector('div')

div.addEventListener('click', () => console.log('Div Clicked'), true)
button.addEventListener('click', () => console.log('Button Clicked', true)

// output
Div Clicked
Button Clicked

useCapture 매개 변수를 사용해 핸들러의 실행 순서를 반대로 할 수 있다.
즉, addEventListener 를 호출할때 useCapture 파라미터에 true 값을 주게되면 버블 단계 대신에 캡쳐 단계에 이벤트 핸들러를 추가한다는 것을 의미한다.

정리해보면

캡쳐 단계: 이벤트가 html에서 목표 요소로 이동한다.
(하향식) 목표 단계: 이벤트가 목표 요소에 도달한다.
(상향식) 버블 단계: 이벤트가 목표 요소에서 html로 이동한다.

브라우저의 암흑 시에 일부 브라우저는 캡처 단계만 지원한 반면 다른 브라우저들은 버블 단계만 지원했다.
일반적으로 버블 단계 핸들러만 사용해도 좋지만 복잡한 상황을 관리하려면 캡처 단계를 알아야한다.

사용자 정의 이벤트 사용

DOM 이벤트 API에서는 사용자 정의 이벤트 타입을 정의하고 다른 이벤트처럼 처리 할 수 있다. 사용자 정의 이벤트를 생성하려면 CustomEvent생성자 함수를 사용한다.

const EVENT_NAME = "FiveCharInputValue";
const input = document.querySelector("input");

input.addEventListener("input", () => {
  const { length } = input.value;
  console.log("input length", length);
  if (length === 5) {
    const time = new Date().getTime();
    const event = new CustomEvent(EVENT_NAME, {
      detail: {
        time,
      },
    });

    input.dispatchEvent(event);
  }
});

input.addEventListener(EVENT_NAME, (e) => {
  console.log("handling custom event...", e.detail);
});

input이벤트를 관리할 때 값 자체의 길이를 확인한다.
값의 길이가 5라면 FiveCharInputValue라는 이벤트를 발생시킨다.
사용자 정의 이벤트를 처리 하려면 addEventListener 메서드로 표준 이벤트 리스너를 추가한다.

TodoMVC에 이벤트 추가

렌더링 엔진 리뷰

2장에서 작성한 마지막 구현의 문제점은 todos 구성 요소가 문자열로 동작한다는 것이다.

const TodoElement = (todo: Todo) => {
  const { text, completed, id } = todo;
  return `
  <li class="todo-item ${completed ? "completed" : ""}" data-id="${id}">
        <div class="display-todo">
          <label for="toggle-todo" class="toggle-todo-label visually-hidden">Toggle Todo</label>
          <input id="toggle-todo" class="toggle-todo-input" type="checkbox" ${completed ? "checked" : ""} />
          <span class="todo-item-text truncate-singleline" tabindex="0">${text}</span>
          <button class="remove-todo-button" title="Remove Todo"></button>
        </div>
        <div class="edit-todo-container">
          <label for="edit-todo" class="edit-todo-label visually-hidden">Edit todo</label>
          <input id="edit-todo" class="edit-todo-input" />
        </div>
      </li>
      `;
      

const Todos = (targetElement: Element, { todos }: State) => {
  const newTodoList = targetElement.cloneNode(true) as Element;
  const todosElements = todos.map(TodoElement).join("");
  newTodoList.innerHTML = todosElements;
  return newTodoList;
};

export default Todos;

기존 코드: 문자열로 만드는 todo-item

리스트의 모든 todo 요소는 문자열로 생성되고 하나로 합쳐진 다음 innerHTML로 부모 리스트에 추가된다. 그러나 문자열에는 이벤트 핸들러를 추가 할 수 없다.

템플릿 요소

document.createElement API를 사용해 비어있는 새 DOM 노드를 생성하는 방법도있지만 코드를 읽고 유지하기 어렵다. 더 나은 방법으로는 index.html 파일의 template 태그 안에 todo 요소의 마크업을 유지하는 것이다. template태그는 이름에서 알 수 있듯이 렌더링 엔진의 ‘스탬프’로 사용할 수 있는 보이지 않는 태그이다.

  <template id="todo-item">
    <li class="todo-item">
      <div class="display-todo">
        <label for="toggle-todo" class="toggle-todo-label visually-hidden"
          >Toggle Todo</label
        >
        <input id="toggle-todo" class="toggle-todo-input" type="checkbox" />
        <span class="todo-item-text truncate-singleline" tabindex="0"
          >${text}</span
        >
        <button class="remove-todo-button" title="Remove Todo"></button>
      </div>
      <div class="edit-todo-container">
        <label for="edit-todo" class="edit-todo-label visually-hidden"
          >Edit todo</label
        >
        <input id="edit-todo" class="edit-todo-input" />
      </div>
    </li>
  </template>

index.html 에 todo-item template요소 생성

let template: HTMLTemplateElement;

const createTodoNode = () => {
  if (!template) {
    template = document.getElementById("todo-item") as HTMLTemplateElement;
  }

  const firstChild = template?.content?.firstElementChild;
  return firstChild?.cloneNode(true) as HTMLElement;
};

const TodoElement = (todo: Todo, index: number) => {
  const { text, completed } = todo;
  const element = createTodoNode();
  if (element) {
    const inputEdit = element.querySelector("input.edit-todo-input") as HTMLInputElement;
    const label = element.querySelector("toggle-todo-label");
    const inputToggle = element.querySelector("input.toggle-todo-input") as HTMLInputElement;
    const buttonDestroy = element.querySelector("button.remove-todo-button") as HTMLButtonElement;
    const spanText = element.querySelector("span.todo-item-text ") as HTMLButtonElement;
    spanText.textContent = text;
    if (inputEdit) inputEdit.value = text;
    if (label) label.textContent = text;

    if (completed) {
      element.classList.add("completed");
      if (inputToggle) inputToggle.checked = true;
    }

    if (buttonDestroy) buttonDestroy.dataset.index = index.toString();

    return element;
  }
};

const Todos = (targetElement: Element, { todos }: State, { deleteItem }: Events) => {
  const newTodoList = targetElement.cloneNode(true) as HTMLUListElement;
  newTodoList.innerHTML = "";

  todos.map(TodoElement)!.forEach((element) => {
    if (element) newTodoList.appendChild(element);
  });

  newTodoList.addEventListener("click", (e: MouseEvent) => {
    const target = e.target as HTMLElement;

    if (target.matches("button.remove-todo-button")) {
      deleteItem(Number(target.dataset.index));
    }
  });
  return newTodoList;
};

export default Todos;

템플릿을 사용해 todo-item 생성

<body>
	<template id="todo-item">
		<!-- todo 항목 내용을 여기에 놓는다 -->
	</template>
	<template id="todo-app">
		<section class="todoapp">
			<!-- 앱 내용을 여기에 놓는다 -->
		</section>
	</template>
	<div id="root">
		<div data-component="app"></div>
	</div>
</body>

전체 앱에 템플릿 사용

let template: HTMLTemplateElement;

const createAppElement = (): HTMLElement => {
  if (!template) {
    template = document.getElementById("todo-app") as HTMLTemplateElement;
  }

  const firstChild = template?.content?.firstElementChild;
  return firstChild?.cloneNode(true) as HTMLElement;
};

const TodoApp = (targetElement: Element, state: State, events: Events) => {
  const newApp = targetElement.cloneNode(true) as Element;

  newApp.innerHTML = "";
  newApp.appendChild(createAppElement());
  addEvents(newApp, events);

  return newApp;
};

import { TodoApp } from "@pages/todo-app";
import { registry, applyDiff } from "@shared/libs";
import { State } from "@shared/types/index.js";
import { getTodos } from "@shared/utils";
import { Counter } from "@widgets/counter";
import { Filters } from "@widgets/filters";
import { Todos } from "@widgets/todos";

registry.add("app", TodoApp);
registry.add("todos", Todos);
registry.add("counter", Counter);
registry.add("filters", Filters);

const state: State = {
  // todos: getTodos(),
  todos: [],
  currentFilter: "All",
};

const render = () => {
  window.requestAnimationFrame(() => {
    const main = document.querySelector("#root") as Element;
    const newMain = registry.renderRoot(main, state);
    applyDiff(document.body, main, newMain);
  });
};

app 이라는 data-component가 새로 생겼다. app 컴포넌트는 새로 작성된 템플릿을 사용해 콘텐츠를 생성한다.

기본 이벤트 처리 아키텍처

문자열 대신 DOM 요소로 동작하는 새로운 렌더링 엔진을 작성했다. 2장에서 작성한 렌더링 엔진은 상태를 가져오고 DOM 트리를 생성하는 순수 함수를 기반으로 한다. 이 시나리오에서는 ‘루프’ 사이에서 이벤트 핸들러를 쉽게 연결할 수 있다. 모든 이벤트 다음에 상태를 조작한 후 새로운 상태로 렌더링 함수를 호출하면 된다.

import { TodoApp } from "@pages/todo-app";
import { registry, applyDiff } from "@shared/libs";
import { Events, State } from "@shared/types/index.js";
import { getTodos } from "@shared/utils";
import { Counter } from "@widgets/counter";
import { Filters } from "@widgets/filters";
import { Todos } from "@widgets/todos";

registry.add("app", TodoApp);
registry.add("todos", Todos);
registry.add("counter", Counter);
registry.add("filters", Filters);

const state: State = {
  // todos: getTodos(),
  todos: [],
  currentFilter: "All",
};

const events: Events = {
  deleteItem: (index: number) => {
    state.todos.splice(index, 1);
    render();
  },
  addItem: (text: string) => {
    state.todos.push({
      text,
      completed: false,
      id: state.todos.length + 1,
    });
    render();
  },
};

const render = () => {
  window.requestAnimationFrame(() => {
    const main = document.querySelector("#root") as Element;
    const newMain = registry.renderRoot(main, state, events);
    applyDiff(document.body, main, newMain);
  });
};

render();

index.js에 이벤트를 가진 컨트롤러 작성

events 객체는 상태를 수정하고 렌더링 함수를 수동으로 호출 하는 간단한 함수이다.
렌더링 엔진의 진입점인 renderRoot 함수는 이벤트를 포함하는 events 를 세 번째 매개 변수를 받는다.
events 는 모든 data-component에 접근할 수 있다.

 import { Events, State } from "@shared/types";
 
 const addEvents = (targetElement: Element, events: Events): void => {
  const inputElement = targetElement.querySelector(".new-todo-input") as HTMLInputElement;
  if (inputElement) {
    inputElement.addEventListener("keypress", (e: KeyboardEvent) => {
      if (e.key === "Enter") {
        console.log("inputElement.value", inputElement.value);

        events.addItem(inputElement.value);
        inputElement.value = "";
      }
    });
  }
};

export const TodoApp = (targetElement: Element, state: State, events: Events) => {
  const newApp = targetElement.cloneNode(true) as Element;

  newApp.innerHTML = "";
  newApp.appendChild(createAppElement());
  addEvents(newApp, events);

  return newApp;
};

addItem 이벤트를 가진 앱 구성 요소

모든 렌더링 주기에 대해 새 DOM 요소를 생성하고 새 todo-item의 값을 삽입하는 데 사용되는 input 핸들러에 이벤트 핸들러를 연결한다.
사용자가 Enter를 누르면 addItem함수가 호출된 후 input 핸들러가 지워진다.

이벤트 위임

이벤트 위임은 대부분의 프론트엔드 프레임워크에서 제공되는 기능으로, 일반적으로 보이지 않게 잘 감춰져 있다.

import { Todo, State, Events } from "@shared/types";
import { createTodoNode } from "../model";

const TodoElement = (todo: Todo, index: number) => {
  const { text, completed } = todo;
  const element = createTodoNode();
  if (element) {
    const inputEdit = element.querySelector("input.edit-todo-input") as HTMLInputElement;
    const label = element.querySelector("toggle-todo-label");
    const inputToggle = element.querySelector("input.toggle-todo-input") as HTMLInputElement;
    const buttonDestroy = element.querySelector("button.remove-todo-button") as HTMLButtonElement;
    const spanText = element.querySelector("span.todo-item-text ") as HTMLButtonElement;
    spanText.textContent = text;
    if (inputEdit) inputEdit.value = text;
    if (label) label.textContent = text;

    if (completed) {
      element.classList.add("completed");
      if (inputToggle) inputToggle.checked = true;
    }

    if (buttonDestroy) buttonDestroy.dataset.index = index.toString();

    return element;
  }
};

const Todos = (targetElement: Element, { todos }: State, { deleteItem }: Events) => {
  const newTodoList = targetElement.cloneNode(true) as HTMLUListElement;
  newTodoList.innerHTML = "";

  todos.map(TodoElement)!.forEach((element) => {
    if (element) newTodoList.appendChild(element);
  });

  newTodoList.addEventListener("click", (e: MouseEvent) => {
    const target = e.target as HTMLElement;

    if (target.matches("button.remove-todo-button")) {
      deleteItem(Number(target.dataset.index));
    }
  });
  return newTodoList;
};

이벤트 위임 기반의 todo-item

todo-item 마다 별도의 이벤트 핸들러를 갖지 않고 있으며 리스트 자체에 하나의 이벤트 핸들러만 연결돼 있다
리스트가 아주 길다면 이 접근 방식으로 성능과 메모리 사용성을 개선 시킬 수 있다.
matches API는 요소가 실제 이벤트 대상인지 확인하는 데 사용한다.

요약

3장에서는 DOM 이벤트 API의 몇 가지 기본 개념을 설명했다.
이벤트 핸들러를 추가하고 삭제하는 방법 버블 단계와 캡처 단계의 차이점, 사용자 정의 이벤트를 생성하는 방법을 배웠다.
프레임워크 없이 애플리케이션이 충분히 성능을 유지할 수 있도록 새주는 중요한 패턴인 이벤트 위임의 개념을 소개했다.

참고

<template>: 콘텐츠 템플릿 요소 - HTML: Hypertext Markup Language | MDN

HTML <template> 요소는 페이지를 불러온 순간 즉시 그려지지는 않지만, 이후 JavaScript를 사용해 인스턴스를 생성할 수 있는 HTML 코드를 담을 방법을 제공합니다.

developer.mozilla.org

[JavaScript] 이벤트 생명주기 (Event Life Cycle)

자바스크립트에서 작업할 때 이벤트는 간단한 호버나 클릭과 같이 흔한 현상이다.각 이벤트마다 동작은 문서 객체 모델(DOM)을 통해 전파된다. DOM은 형제, 자식 및 부모 요소를 포함한 트리 구조

velog.io

Event reference | MDN

Events are fired to notify code of "interesting changes" that may affect code execution. These can arise from user interactions such as using a mouse or resizing a window, changes in the state of the underlying environment (e.g. low battery or media events

developer.mozilla.org

[프레임워크 없는 프론트엔드 개발] - 2장. 렌더링

_OIL — Wed, 3 Jul 2024 13:06:41 +0900

모든 웹 애플리케이션에서 가장 중요한 기능 중 하나는 데이터의 표시됩니다
데이터를 표시한다는 것은 요소를 화면이나 다른 출력 장치에 렌더링하는 것을 의미합니다
W3C(world Wide Web Consortium)는 프로그래밍 방식으로 요소를 렌더링 하는 방식을 DOM(Document Object Model)로 정의했습니다.
2장의 목적은 프레임워크 없이 DOM을 효과적으로 조작하는 방법을 배우는 데 있습니다.

문서 객체 모델

DOM은 웹 애플리케이션을 구성하는 요소를 조작할 수 있는 API입니다.

<html>
    <body>
        <table>
            <tr>
                <th>Framework</th>
                <th>Github stars</th>
            </tr>
            <tr>
                <th>Vue</th>
                <th>118917</th>
            </tr>
            <tr>
                <th>React</th>
                <th>115392</th>
            </tr>
        </table>
    </body>
</html>

2-1. 간단한 HTML 테이블

const SELECTOR = 'tr:nth-child(3) > td'
const cell = document.querySelector(SELECTOR)
cell.style.background = 'red'

React 셀의 색상 변경

기술적 관점에서 보면 모든 HTML페이지(또는 그 일부)는 트리로 구성되고 그림 2-2처럼 DOM으로 표현됩니다. 그리고 HTML 요소로 정의된 트리를 관리하는 방법은 아래와 같은 형식을 사용합니다.

코드는 간단하게 표준 CSS 선택자를 사용해 올바른 셀을 선택한 다음 셀 노드의 style 속성을 변경합니다. querySelector 메서드는 Node 메서드입니다. Node는 HTML 트리에서 노드를 나타내는 기본 인터페이스입니다.

렌더링 성능 모니터링

웹용 렌더링 엔진을 설계할 때 중요한 요소는 가독성과 유지 관리성 그리고 성능입니다.
렌더링 엔진을 처음부터 새로 작성하기로 결정했다면 이해하고 발전시키기 쉽게 설계해야합니다.

렌더링 엔진의 성능을 모니터링하는 여러 도구를 살펴보자!

크롬 개발자 도구

FPS(Frames Per Second) : 렌더링 성능 모니터링에서 사용할 수 있는 기능 중 하나로 초당 프레임 수를 추적할 수 있습니다. 크롬 개발자 도구 → cmd/ctrl + Shift + P : FPS 및 GPU 사용량 확인 가능

웹 개발에서 권장되는 FPS(Frames Per Second)는 일반적으로 60 FPS입니다. 일반적으로 대부분의 웹 브라우저에서는 W3C 권장사항에 따라 디스플레이 주사율과 일치됩니다.

stats.js

애플리케이션의 FPS를 모니터링할 수 있는 라이브러리중 하나입니다
- 프레임 & 할당된 메가바이트의 메모리 렌더링에 필요한 밀리초 표시 가능합니다
- 어떤 웹 사이트에도 위젯을 연결할 수 있는 간단한 북마크렛(bookmarklet)기능 제공합니다

Bookmarklet은 북마크를 통해 실행할 수 있는 작은 자바스크립트 프로그램입니다. 북마크를 클릭하면, 해당 자바스크립트 코드가 현재 브라우저 탭에서 실행됩니다. 북마크렛 만드는 방법

사용자 정의 성능 위젯

function fps() {
  let panel: HTMLDivElement | null = null;
  let start: number | null = null;
  let frames: number = 0;

  function create(): HTMLDivElement {
    const div: HTMLDivElement = document.createElement("div");

    div.style.position = "fixed";
    div.style.left = "0px";
    div.style.top = "0px";
    div.style.width = "50px";
    div.style.height = "50px";
    div.style.backgroundColor = "black";
    div.style.color = "white";

    return div;
  }

  function resetFramesAndStart(now: number): void {
    if (panel !== null) {
      panel.innerText = frames.toString();
    }
    frames = 0;
    start = now;
  }

  function tick(): void {
    frames++;
    const now: number = window.performance.now();
    if (start !== null && now >= start + 1000) {
      resetFramesAndStart(now);
    }
    window.requestAnimationFrame(tick);
  }

  function initializePanel(parent: HTMLElement): void {
    panel = create();
    if (panel !== null) {
      parent.appendChild(panel);
    }
  }

  function init(parent: HTMLElement = document.body): void {
    initializePanel(parent);

    window.requestAnimationFrame(() => {
      start = window.performance.now();
      tick();
    });
  }

  return init();
}

export default fps;

fps 함수는 panel, start, frames라는 세 가지 변수를 선언합니다. panel은 FPS를 표시하는 HTML 요소를 참조하고, start는 FPS 계산을 시작하는 시간을 저장하며, frames는 계산된 프레임 수를 저장합니다.
create 함수는 FPS를 표시하는 HTML 요소를 생성하고 반환합니다.
resetFramesAndStart 함수는 프레임 수를 0으로 재설정하고, 시작 시간을 현재 시간으로 설정합니다. 또한, panel이 null이 아닌 경우, panel의 텍스트를 현재 프레임 수로 설정합니다.
tick 함수는 프레임 수를 증가시키고, 현재 시간이 시작 시간보다 1초 이상 지났는지 확인합니다. 만약 1초 이상 지났다면, resetFramesAndStart 함수를 호출하여 프레임 수와 시작 시간을 재설정합니다. 그리고 window.requestAnimationFrame을 사용하여 tick 함수를 다시 호출합니다.
initializePanel 함수는 create 함수를 호출하여 FPS를 표시하는 HTML 요소를 생성하고, 이 요소를 부모 요소에 추가합니다.
init 함수는 initializePanel 함수를 호출하여 FPS를 표시하는 HTML 요소를 초기화하고, window.requestAnimationFrame을 사용하여 tick 함수를 호출합니다. 이 때, 시작 시간을 현재 시간으로 설정합니다.
마지막으로, fps 함수는 init 함수를 호출하여 FPS 계산을 시작합니다. 이 함수는 init 함수의 반환값을 반환합니다.

렌더링 함수

이번 장은 순수하게 함수를 사용해 요소를 DOM에 렌더링하는 다양한 방법을 분석해봅니다. 순수 함수로 요소를 렌더링한다는 것은 DOM 요소가 애플리케이션의 상태에만 의존한다는 것을 의미합니다.

view = f(state)

순수 함수 렌더링의 수학적 표현

Todo MVC

2장의 예제를 위해 TodoMVC(https://todomvc.com/) 템플릿을 사용합니다.
책에서 사용된 코드는 https://github.com/Apress/frameworkless-front-end-development/tree/747d119cd515f74d54cea67e92a31f45e0a803ea/Chapter02 입니다.

순수 함수 렌더링

index.html은 TodoMVC 애플리케이션의 골격을 나타냅니다.

<html>
  <head>
    <link rel="shortcut icon" href="../favicon.ico" />
    <link
      rel="stylesheet"
      href="https://cdn.jsdelivr.net/npm/todomvc-common@1.0.5/base.css"
    />
    <link
      rel="stylesheet"
      href="https://cdn.jsdelivr.net/npm/todomvc-app-css@2.1.2/index.css"
    />
    <script src="https://cdnjs.cloudflare.com/ajax/libs/Faker/3.1.0/faker.js"></script>
    <title>Frameworkless Frontend Development: Rendering</title>
  </head>

  <body>
    <section class="todoapp">
      <header class="header">
        <h1>todos</h1>
        <input
          class="new-todo"
          placeholder="What needs to be done?"
          autofocus
        />
      </header>
      <section class="main">
        <input id="toggle-all" class="toggle-all" type="checkbox" />
        <label for="toggle-all">Mark all as complete</label>
        <ul class="todo-list"></ul>
      </section>
      <footer class="footer">
        <span class="todo-count">1 Item Left</span>
        <ul class="filters">
          <li>
            <a href="#/">All</a>
          </li>
          <li>
            <a href="#/active">Active</a>
          </li>
          <li>
            <a href="#/completed">Completed</a>
          </li>
        </ul>
        <button class="clear-completed">Clear completed</button>
      </footer>
    </section>
    <footer class="info">
      <p>Double-click to edit a todo</p>
      <p>
        Created by
        <a href="http://twitter.com/thestrazz86">Francesco Strazzullo</a>
      </p>
      <p>Thanks to <a href="http://todomvc.com">TodoMVC</a></p>
    </footer>
    <script type="module" src="index.js"></script>
  </body>
</html>

index.html

이 어플리케이션을 동적으로 만들려면 to-do 리스트 데이터를 가져와 다음을 업데이트 해야 합니다.

필터링된 todo 리스트를 가진 ul
완료되지 않은 todo 수를 가진 span
선택된 filter를 강조 표시하기 위해 filters하위의 li > a class에 selected 추가

const getTodoElement = (todo) => {
  const { text, completed } = todo;

  return `
  <li ${completed ? 'class="completed"' : ""}>
    <div class="view">
      <input 
        ${completed ? "checked" : ""}
        class="toggle" 
        type="checkbox">
      <label>${text}</label>
      <button class="destroy"></button>
    </div>
    <input class="edit" value="${text}">
  </li>`;
};

const getTodoCount = (todos) => {
  const notCompleted = todos.filter((todo) => !todo.completed);

  const { length } = notCompleted;
  if (length === 1) {
    return "1 Item left";
  }

  return `${length} Items left`;
};

export default (targetElement, state) => {
  const { currentFilter, todos } = state;

  const element = targetElement.cloneNode(true); //노드 복사

  const list = element.querySelector(".todo-list");
  const counter = element.querySelector(".todo-count");
  const filters = element.querySelector(".filters");

  list.innerHTML = todos.map(getTodoElement).join("");
  counter.textContent = getTodoCount(todos);

  Array.from(filters.querySelectorAll("li a")).forEach((a) => {
    if (a.textContent === currentFilter) {
      a.classList.add("selected");
    } else {
      a.classList.remove("selected");
    }
  });

  return element;
};

view.js

getTodoElement(todo): 이 함수는 하나의 todo 항목을 받아서 HTML 요소를 문자열로 반환합니다. 이 문자열은 각 todo 항목의 상태와 텍스트를 반영합니다.
getTodoCount(todos): 이 함수는 완료되지 않은 todo 항목의 수를 반환합니다. 이 수는 "1 Item left" 또는 "{length} Items left" 형식의 문자열로 반환됩니다.
export default (targetElement, state): 이 함수는 대상 HTML 요소와 상태를 인자로 받아서, 상태에 따라 대상 요소를 업데이트하고 새로운 요소를 반환합니다. 이 함수는 todo 항목의 목록, 완료되지 않은 항목의 수, 그리고 현재 필터 상태를 업데이트합니다.
1. 기본으로 사용되는 targetElement를 받습니다.
2. 원래 노드를 복제하고 state 매개 변수 사용을 통해 업데이트 합니다.
3. 새 노드 반환
  - 본 코드에서의 DOM 수정은 가상(virtual)이며, 분리된(detached) **요소 로 작업하고 있습니다
    - 분리된 요소 생성을 위해 cloneNode메소드로 기존 노드 복제 합니다.
    - 새로 생성된 DOM element는 targetElement 와 동일한 복제본이지만 targetElement 는 전혀 관련이 없습니다.
  - 아직 DOM의 실제 수정 사항이 커밋되지 않은 상태입니다
    - 분리된 DOM요소의 수정이 이루어질 경우 성능 향상
    - view.js 를 실제 DOM에 연결 하기 위해 컨트롤러인 index.js를 사용합니다.

import getTodos from "./getTodos.js";
import view from "./view.js";

const state = {
  todos: getTodos(),
  currentFilter: "All",
};

const main = document.querySelector(".todoapp");

window.requestAnimationFrame(() => {
  const newMain = view(main, state);
  main.replaceWith(newMain);
});

control 역할을 하는 index.js

control 역할을 하는 index.js처럼 간단한 ‘렌더링 엔진은’ requestAnimationFrame을 기반으로 합니다.
- requestAnimationFrame 콜백 내에서 DOM작업을 수행하면 더 휴율적이게 됩니다.
- requestAnimationFrame는 메인 스레드를 차단하지 않으며 실행될 다시 그리기(repaint) 가 이벤트 루프에서 스케줄링되기 직전에 실행됩니다.
replaceWith: Element.replaceWith()메서드는 부모의 하위 목록에서 이 Element 노드 또는 문자열 객체 집합으로 대체합니다. 문자열 객체는 동등한 텍스트 노드로 삽입됩니다.

const { faker } = window;

const createElement = () => ({
  text: faker.random.words(2),
  completed: faker.random.boolean(),
});

const repeat = (elementFactory, number) => {
  const array = [];
  for (let index = 0; index < number; index++) {
    array.push(elementFactory());
  }
  return array;
};

export default () => {
  const howMany = faker.random.number(10);
  return repeat(createElement, howMany);
};

model역할을 하는 getTodos.js

여기서 작성하는 데이터 모델은 랜덤 데이터 생성에 유용한 라이브러리인 Faker.js로 생성된 랜덤 배열입니다.

코드 리뷰

여기서의 렌더링 방식은 requestAnimationFrame과 가상 노드 조작을 사용해 충분한 성능을 보여줍니다. 하지만 뷰 함수는 읽기 쉽지 않습니다. 코드는 두 가지 중요한 문제를 갖고 있습니다.

하나의 거대한 함수: 여러 DOM 요소를 조작하는 함수가 단 하나 뿐입니다. 이는 상황을 아주 쉽게 복잡하게 만들 수 있습니다.
동일한 작업을 수행하는 여러 방법: DOM조작을 위해 필요한 요소를 각각의 query selector로 접근 하지만 DOM을 조작하는 방법은 모두 다름
- list: 문자열로 리스트 항목 생성 후 innerHTML 에 값을 넣어줍니다.
- count : 완료되지 않은 todo의 개수를 textContent 에 넣어줍니다.
- filter: ‘selected’ class를 classList 로 관리 하고 있습니다.

위 문제를 해결 하기 위해 view.js 를 조금더 작은 함수로 분리 했을 때의 예제 코드입니다.

view폴더를 만들고 기능에 맞게 counter.js, filter.js, todos.js 파일로 코드를 분리하고 app.js에서 만들어직 각각의 새 노드들을 replaceWith 메서드로 대체 해줍니다. 위 예제 코드는 구성 요소 라이브러의 첫 번째 초안이 됩니다.

frameworkless-front-end-development/Chapter02/02 at 747d119cd515f74d54cea67e92a31f45e0a803ea · Apress/frameworkless-front-end-d

Source code for 'Frameworkless Front-End Development' by Francesco Strazzullo - Apress/frameworkless-front-end-development

github.com

구성 요소 함수

구성 요소 기반의 애플리케이션을 작성하려면 구성 요소 간의 상호작용에 선언적 방식을 사용해야 합니다.

https://github.com/Apress/frameworkless-front-end-development/tree/master/Chapter02/03는 구성 요소 레지스트리를 갖는 렌더링 엔진의 예입니다. Todo 앱에서는 todos, counters, filters의 세 가지 구성 요소를 가집니다.

<html>

<head>
    <link rel="shortcut icon" href="../favicon.ico" />
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/todomvc-common@1.0.5/base.css">
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/todomvc-app-css@2.1.2/index.css">
    <script src="https://cdnjs.cloudflare.com/ajax/libs/Faker/3.1.0/faker.js"></script>
    <title>
        Frameworkless Frontend Development: Rendering
    </title>
</head>

<body>
    <section class="todoapp">
        <header class="header">
            <h1>todos</h1>
            <input 
                class="new-todo" 
                placeholder="What needs to be done?" 
                autofocus>
        </header>
        <section class="main">
            <input 
                id="toggle-all" 
                class="toggle-all" 
                type="checkbox">
            <label for="toggle-all">
                Mark all as complete
            </label>
            <ul class="todo-list" data-component="todos">
            </ul>
        </section>
        <footer class="footer">
            <span 
                class="todo-count" 
                data-component="counter">
                    1 Item Left
            </span>
            <ul class="filters" data-component="filters">
                <li>
                    <a href="#/">All</a>
                </li>
                <li>
                    <a href="#/active">Active</a>
                </li>
                <li>
                    <a href="#/completed">Completed</a>
                </li>
            </ul>
            <button class="clear-completed">
                Clear completed
            </button>
        </footer>
    </section>
    <footer class="info">
        <p>Double-click to edit a todo</p>
        <p>Created by <a href="http://twitter.com/thestrazz86">Francesco Strazzullo</a></p>
        <p>Thanks to <a href="http://todomvc.com">TodoMVC</a></p>
    </footer>
    <script type="module" src="index.js"></script>
</body>

</html>

2-11. 구성 요소를 사용하고자 데이터 속성을 사용하는 앱

2-11. 구성 요소를 사용하고자 데이터 속성을 사용하는 앱에서는 todos, counters, filters의 세 가지 구성 요소를 data-component 속성에 넣었습니다.
이 속성은 뷰 함수에서의 호출에서 사용됩니다.
컴포넌트 라이브러리를 생성하기 위한 또 다른 필수 조건은 registry로 입니다. 레지스트리는 애플리케이션에서 사용할 수 있는 모든 구성 요소의 인덱스 입니다.

const registry = {
  todos: todosView,
  counter: counterView,
  filters: filtersView,
};

간단한 구성 요소 레지스트리

레지스트리의 키는 data-component 속성 값과 일치 합니다.(이것이 구성 요소 기반 렌더링 엔진의 핵심 메커니즘입니다.)
이 메커니즘은 루트 컨테이너 뿐만 아니라 생성할 모든 컴포넌트에 적용돼야 합니다. 이렇게 하면 모든 컴포넌트가 다른 컴포넌트 안에서 불러와 사용될 수 있습니다. 이런 재사용성은 컴포넌트 기반 애플리케이션에서 필수적입니다.
모든 컴포넌트가 data-component 속성의 값을 읽고 올바른 함수를 자동으로 호출하는 기본 구성 요소에 상속돼야합니다. 하지만 순수 함수로 작성하고 있기 때문에 실제로는 이 기본 객체에서 상속 받을 수 없어서 구성 요소를 래핑하는 고차 함수를 생성해야 합니다.

const renderWrapper = (component) => {
  return (targetElement, state) => {
    const element = component(targetElement, state);

    const childComponents = element.querySelectorAll("[data-component]");

    Array.from(childComponents).forEach((target) => {
      const name = target.dataset.component;

      const child = registry[name];
      if (!child) {
        return;
      }

      target.replaceWith(child(target, state));
    });

    return element;
  };
};

고차 함수 렌더링

renderWrapper(component): 이 함수는 컴포넌트를 인자로 받아서, 새로운 함수를 반환합니다. 반환된 함수는 targetElement와 state를 인자로 받아서 컴포넌트를 렌더링합니다.
반환된 함수 내부에서는 먼저 component(targetElement, state)를 호출하여 컴포넌트를 렌더링하고, 결과로 나온 DOM 요소를 element에 저장합니다.
element.querySelectorAll('[data-component]'): 이 코드는 element 내부에서 data-component 속성을 가진 모든 자식 컴포넌트를 찾습니다. 이 속성은 자식 컴포넌트의 이름을 나타냅니다.
Array.from(childComponents).forEach(target => {...}): 찾아낸 자식 컴포넌트들을 배열로 변환한 후, 각각에 대해 반복 처리를 합니다. 반복 처리 내부에서는 registry에서 해당 컴포넌트의 렌더링 함수를 찾아 호출하고, 결과로 나온 DOM 요소로 기존의 자식 컴포넌트를 대체합니다.

const add = (name, component) => {
  registry[name] = renderWrapper(component);
};

2-14 레지스트리 접근자 메서드

레지스트리에 구성 요소를 추가하려면 2-14와 같이 이전 함수로 구성 요소를 래핑하는 간단한 함수가 필요합니다.

const renderRoot = (root, state) => {
  const cloneComponent = (root) => {
    return root.cloneNode(true);
  };

  return renderWrapper(cloneComponent)(root, state);
};

2-15 구성 요소 기반 애플리케이션의 부팅 함수

최초 DOM 요소에서 렌더링을 시작하려면 애플리케이션의 루트를 렌더링하는 메서드를 제공해야 합니다.

import getTodos from "./getTodos.js";
import todosView from "./view/todos.js";
import counterView from "./view/counter.js";
import filtersView from "./view/filters.js";

import registry from "./registry.js";

registry.add("todos", todosView);
registry.add("counter", counterView);
registry.add("filters", filtersView);

const state = {
  todos: getTodos(),
  currentFilter: "All",
};

window.requestAnimationFrame(() => {
  const main = document.querySelector(".todoapp");
  const newMain = registry.renderRoot(main, state);
  main.replaceWith(newMain);
});

구성 요소 레지스트리를 사용하는 컨트롤러

동적 데이터 렌더링

이전 예제에서는 정적 데이터를 사용했습니다. 그러나 실제 애플리케이션에서는 사용자나 시스템의 이벤트에 의해 데이터가 변경됩니다.

가상 DOM

리액트에 의해 유명해진 가상 DOM 개념은 선언적 렌더링 엔진의 성능을 개선시키는 방법입니다.
UI 표현은 메모리에 유지되고 ‘실제’ DOM과 동기화 됩니다.
실제 DOM은 가능한 적은 작업을 수행되어야 합니다. 우리는 이 과정을 조정(reconciliation)이라고 부릅니다.
가상 DOM의 핵심은 diff 알고리즘입니다. 이 알고리즘은 실제 DOM을 문서에서 분리된 새로운 DOM element의 사본으로 바꾸는 가장 빠른 방법을 찾아냅니다.

간단한 가상 DOM 구현

const isNodeChanged = (node1, node2) => {
  const n1Attributes = node1.attributes;
  const n2Attributes = node2.attributes;
  if (n1Attributes.length !== n2Attributes.length) {
    return true;
  }

  const differentAttribute = Array.from(n1Attributes).find((attribute) => {
    const { name } = attribute;
    const attribute1 = node1.getAttribute(name);
    const attribute2 = node2.getAttribute(name);

    return attribute1 !== attribute2;
  });

  if (differentAttribute) {
    return true;
  }

  if (
    node1.children.length === 0 &&
    node2.children.length === 0 &&
    node1.textContent !== node2.textContent
  ) {
    return true;
  }

  return false;
};

const applyDiff = (parentNode, realNode, virtualNode) => {
  if (realNode && !virtualNode) {
    realNode.remove();
    return;
  }

  if (!realNode && virtualNode) {
    parentNode.appendChild(virtualNode);
    return;
  }

  if (isNodeChanged(virtualNode, realNode)) {
    realNode.replaceWith(virtualNode);
    return;
  }

  const realChildren = Array.from(realNode.children);
  const virtualChildren = Array.from(virtualNode.children);

  const max = Math.max(realChildren.length, virtualChildren.length);
  for (let i = 0; i < max; i++) {
    applyDiff(realNode, realChildren[i], virtualChildren[i]);
  }
};

export default applyDiff;

코드는 크게 두 부분으로 나뉩니다: isNodeChanged 함수와 applyDiff 함수입니다.

isNodeChanged 함수

이 함수는 두 노드(HTML 요소)를 비교하여 변경이 필요한지 여부를 판단합니다. 다음과 같은 경우에 변경이 필요하다고 판단합니다:

속성의 개수가 다른 경우: 두 노드의 속성 개수가 다르면, 무조건 변경이 필요합니다.
속성의 값이 다른 경우: 두 노드의 속성을 하나씩 비교하여 값이 다른 속성이 하나라도 있으면 변경이 필요합니다.
자식 노드가 없고 텍스트 내용이 다른 경우: 두 노드 모두 자식 노드가 없으면서 텍스트 내용이 다를 경우 변경이 필요합니다.

applyDiff 함수

이 함수는 실제 DOM 노드(realNode)와 가상 DOM 노드(virtualNode)를 비교하여, 필요한 변경사항을 실제 DOM에 적용합니다. 다음과 같은 경우에 대해 처리합니다:

실제 노드는 있지만 가상 노드가 없는 경우: 실제 노드를 DOM에서 제거합니다.
실제 노드는 없지만 가상 노드가 있는 경우: 가상 노드를 실제 DOM에 추가합니다.
두 노드가 다른 경우: isNodeChanged 함수를 사용하여 두 노드가 다르다고 판단되면, 실제 노드를 가상 노드로 교체합니다.
자식 노드 비교: 실제 노드와 가상 노드의 자식 노드들을 재귀적으로 비교하여, 각 자식 노드에 대해서도 applyDiff 함수를 호출합니다. 이 과정에서 자식 노드들 사이의 차이점도 적용됩니다.

이 코드는 DOM의 변경사항을 최소화하여 성능을 개선하는 데 도움을 줍니다. 가상 DOM과 실제 DOM 사이의 차이점만을 적용함으로써, 불필요한 DOM 조작을 줄이고 애플리케이션의 반응 속도를 향상시킵니다.

참고

[리액트] Virtual DOM과 diffing

주제

joong-sunny.github.io

Element: classList property - Web APIs | MDN

The Element.classList is a read-only property that returns a live DOMTokenList collection of the class attributes of the element. This can then be used to manipulate the class list.

developer.mozilla.org

Element: replaceWith() method - Web APIs | MDN

The Element.replaceWith() method replaces this Element in the children list of its parent with a set of Node or string objects. String objects are inserted as equivalent Text nodes.

developer.mozilla.org

웹 애니메이션 최적화 requestAnimationFrame 가이드

자바스크립트 웹 애니메이션 웹페이지의 애니메이션을 구현할때 CSS의 animatoin , transition , transform 속성을 통해 구현할 수도 있지만, 보다 사용자와의 복잡한 상호작용을 구현하게 하기 위해 Javasc

inpa.tistory.com

Window: requestAnimationFrame() method - Web API | MDN

화면에 애니메이션을 업데이트할 준비가 될 때마다 이 메서드를 호출해야 합니다. 이는 브라우저가 다음 리페인트를 수행하기 전에 애니메이션 함수를 호출하도록 요청합니다. 콜백의 수는 보

developer.mozilla.org

Performance: now() method - Web APIs | MDN

The performance.now() method returns a high resolution timestamp in milliseconds. It represents the time elapsed since Performance.timeOrigin (the time when navigation has started in window contexts, or the time when the worker is run in Worker and Service

developer.mozilla.org

북마클릿 만들고 북마크(즐겨찾기)에 올리기(예제 : 브라우저 사이즈 표시)

북마클릿 만들고 북마크(즐겨찾기)에 올리기(예제 : 브라우저 사이즈 표시) 자바스크립트를 어느 정도 이해하고 간단한 스크립트를 작성할 수있다면 브라우저에서 원하는 기능을 구현할 수있는

nuknukhan.tistory.com

GitHub - mrdoob/stats.js: JavaScript Performance Monitor

JavaScript Performance Monitor. Contribute to mrdoob/stats.js development by creating an account on GitHub.

github.com

Node - Web APIs | MDN

The DOM Node interface is an abstract base class upon which many other DOM API objects are based, thus letting those object types to be used similarly and often interchangeably. As an abstract class, there is no such thing as a plain Node object. All objec

developer.mozilla.org

What is the Document Object Model?

What is the Document Object Model? Editors Jonathan Robie, Texcel Research Introduction The Document Object Model (DOM) is a programming API for HTML and XML documents. It defines the logical structure of documents and the way a document is accessed and ma

www.w3.org

[프레임워크 없는 프론트엔드 개발] - 1장. 프레임워크에 대한 이야기

_OIL — Mon, 24 Jun 2024 01:01:47 +0900

1장. 프레임워크에 대한 이야기

프레임워크는 필요 없다. 중요한 것은 그림이지 프레임이 아니다 - 클라우스 킨스키

1장에서는 프레임워크에 대한 저자의 생각과 프레임워크 없이 개발하는 방법을 배우는 것이 왜 중요한지에 대한 저자의 믿음으로 시작한다. 프레임워크 없이 작업하는 방법을 배우고 나면 이 방법이 자신의 프로젝트에 적합한 선택인지 알 수 있게 될 것이다.

프레임워크란?

무언가를 만들 수 있는 지지 구조 - 캠브리지 사전의 정의

프레임워크는 특정 문제를 해결하기 위한 뼈대 또는 틀을 제공하는 구조를 말합니다. - GPT

더 자세히 설명하면:

미리 만들어진 구성 요소와 규칙을 제공하여 개발자가 복잡한 작업을 효율적으로 수행할 수 있도록 돕는 소프트웨어 환경입니다.

재사용 가능한 코드와 구조를 제공하여 개발 시간을 단축하고 코드 품질을 향상시킵니다.

일관성과 표준화를 유지하여 팀 개발을 용이하게 합니다.

예를 들어:

웹 개발 프레임워크: Spring, Django, Ruby on Rails 등은 웹 애플리케이션 개발에 필요한 기본적인 구조와 기능을 제공합니다.

모바일 개발 프레임워크: React Native, Flutter 등은 모바일 앱 개발에 필요한 UI 구성 요소, 네트워킹 기능, 데이터베이스 연동 등을 제공합니다.

데이터 분석 프레임워크: Pandas, Scikit-learn 등은 데이터 분석에 필요한 데이터 처리, 머신러닝 알고리즘, 시각화 도구 등을 제공합니다.

프레임워크를 사용하면 다음과 같은 이점이 있습니다.

개발 시간 단축: 미리 만들어진 구성 요소를 사용하여 개발 시간을 절약할 수 있습니다.

코드 품질 향상: 일관성과 표준화를 유지하여 코드 품질을 향상시킬 수 있습니다.

유지보수 편의성: 코드 구조가 일관성 있게 구성되어 유지보수가 편리합니다.

팀 개발 효율성 증대: 팀원 간의 협업을 용이하게 합니다.

결론적으로 프레임워크는 개발자가 더 빠르고 효율적으로 소프트웨어를 개발할 수 있도록 돕는 필수적인 도구입니다.

프레임워크와 라이브러리의 비교

프레임워크

앵귤러: 서비스, 구성 요소와 파이프 같은 기본 요소를 사용해 애플리케이션을 빌드하는 데 필요한 구조를 제공한다.

라이브러리

로대쉬(Loadash)와 모멘트 같이(Moment) 애플리케이션 코드를 어떻게 구성해야 하는지에 대해 특별한 형식을 요구하지 않는다.

프레임워크와 라이브러리의 차이: 프레임워크는 코드를 호출한다. 코드는 라이브러리를 호출한다. 프레임워크는 내부적으로 하나 이상의 라이브러리를 사용할 수 있지만 개발자가 모듈식 프레임워크를 선택하면 프레임워크를 단일 단위나 여러 모듈로 보는 개발자에게는 이러한 사실이 숨겨진다.

그렇다면 React는 라이브러리일까? 아니면 프레임워크일까? 정답은 아래에

프레임워크 방식

Moment.js같은 라이브러리는 개발자가 어떻게 코드에 통합하는지 강요하지 않는다. 이에 반해 앵귤러는 매우 독선적이다. 다음 절에서는 몇 가지 제약 조건을 알아본다.

1. 언어

앵귤러는 TypeScript를 사용한다. TypeScript는 일반 자바스크립트 컴파일 되는 자바스크립트의 형식화된 슈퍼 세트다. 유형 검사 외에도 어노테이션 같은 원본 언어에서는 존재하지 않는 여러 기능을 제공한다.

2. 의존성 주입

요소가 앵귤러 애플리케이션에서 통신할 수 있게 하려면 유형에 따라 의존성 주입 메커니즘을 사용해 요소를 주입해야 한다.

의존성 주입(Dependency Injection, DI)은 애플리케이션의 클래스들이 자신의 의존성을 직접 생성하지 않고 외부에서 제공받는 설계 패턴이다. 이 방식은 코드의 재사용성, 테스트 용이성, 유지보수성을 크게 향상시킨다. - GPT
앵귤러 의존성 주입 이해하기

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root' // root 인젝터에 등록되어 애플리케이션 전역에서 사용 가능
})
export class DataService {
  constructor() { }

  getData() {
    return ['Data1', 'Data2', 'Data3'];
  }
}

서비스 정의 및 데코레이션

import { Component, OnInit } from '@angular/core';
import { DataService } from './data.service';

@Component({
  selector: 'app-data',
  templateUrl: './data.component.html',
  styleUrls: ['./data.component.css']
})
export class DataComponent implements OnInit {
  data: string[];

  // DataService 의존성을 주입
  constructor(private dataService: DataService) { }

  ngOnInit() {
    this.data = this.dataService.getData();
  }
}

의존성 주입

// 특정 모듈에서만 서비스 제공
@NgModule({
  providers: [DataService]
})
export class DataModule { }

의존성 등록

3. 옵저버블

앵귤러는 옵저버블(observable)을 사용한 반응형 프로그래밍용 라이브러리인 RxJS를 기반으로 설계됐다. 그래서 데이터를 가져오러면 Observable객체의 subscribe메서드를 사용해야된다. 이 접근 방식은 HTTP 요청이 프라미스 처럼 설계되는 다른 프론트엔드 프레임워크와 다르다

옵저버블을 사용하지 않는 앵귤러 서비스와 구성 요소

// 1-5) 옵저버블을 사용하지 않은 앵귤러 서비스

import axios from 'axios';
const URL = '<http://example.api.com/>';

export default {
    list() {
        return axios.get(URL);
    }
}

// 1-6) 옵저버블을 사용하지 않는 앵귤러 구성 요소
import people from 'people.js';

export class PeopleList {
    load() {
        people
            .list()
            .then(people => {
                this.people = people
        });
    }
}

옵저버블을 사용한 앵규러의 데이터 통신 방식

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class DataService {

  private apiUrl = '<https://jsonplaceholder.typicode.com/posts>';

  constructor(private http: HttpClient) { }

  getPosts(): Observable {
    return this.http.get(this.apiUrl);
  }
}

서비스 생성

import { Component, OnInit } from '@angular/core';
import { DataService } from '../data.service';

@Component({
  selector: 'app-posts',
  templateUrl: './posts.component.html',
  styleUrls: ['./posts.component.css']
})
export class PostsComponent implements OnInit {

  posts: any[] = [];

  constructor(private dataService: DataService) { }

  ngOnInit(): void {
    this.dataService.getPosts().subscribe(
      data => this.posts = data,
      error => console.error('There was an error!', error)
    );
  }
}

컴포넌트에서 서비스 사용

<div *ngIf="posts.length > 0">
  <h2>Posts</h2>
  <ul>
    <li *ngFor="let post of posts">
      {{ post.title }}
    </li>
  </ul>
</div>
<div *ngIf="posts.length === 0">
  <p>No posts available.</p>
</div>

HTML 템플릿 설정

리액트에 대해 이야기해보자

리액트 홈페이지에서 리액트는 ‘사용자 인터페이스 구축을 위한 자바스크립트 라이브러리’라고 정의돼 있다.

그러나 현실은 이보다 훨씬 더 복잡하다!

리액트의 주요 제약 사항

선언적 패러다임을 사용한다.
DOM을 직접 조작하는 대신 구성 요소의 상태를 수정한다.

선언적 패턴으로 PoseExample 컴포넌트 구현

import React, { useState } from 'react';
import posed from 'react-pose';

const Box = posed.div({
  hidden: { opacity: 0 },
  visible: { opacity: 1 },
  transition: {
    ease: 'linear',
    duration: 500
  }
});

const PoseExample = () => {
  const [isVisible, setIsVisible] = useState(true);

  const toggle = () => {
    setIsVisible(!isVisible);
  };

  const pose = isVisible ? 'visible' : 'hidden';

  return (
    <div>
      <Box className='box' pose={pose} />
      <button onClick={toggle}>Toggle</button>
    </div>
  );
};

export default PoseExample;

PoseExample 컴포넌트

명령형패턴으로 PoseExample 컴포넌트 구현

const PoseExample = () => {
  const [isVisible, setIsVisible] = useState(true);
  const boxRef = useRef(null);

  useEffect(() => {
    const box = boxRef.current;
    if (isVisible) {
      box.style.opacity = 1;
    } else {
      box.style.opacity = 0;
    }
    box.style.transition = 'opacity 0.5s linear';
  }, [isVisible]);

  const toggle = () => {
    setIsVisible(!isVisible);
  };

  return (
    <div>
      <div ref={boxRef} className='box' />
      <button onClick={toggle}>Toggle</button>
    </div>
  );
};

export default PoseExample;

// Box.css
.box {
  width: 100px;
  height: 100px;
  background-color: red;
  opacity: 1; /* 초기 상태 */
  transition: opacity 0.5s linear; /* 트랜지션 정의 */
}

리액트 개발자라면 명령형 패턴으로 PoseExample 컴포넌트를 구현 한 예제가 매우 이상하게 보일 것이다. 명령형으로 Box를 움직이기 때문이다! 이 ‘기묘함(strangeness)’ 이 리액트는 라이브러리가 아닌 프레임워크라고 저자가 믿는 이유다. 저자는 이것이 코드 때문이 아니라 리액트 커뮤니티에서 이를 사용할 때 수용한 제약 사항 때문이라고 믿는다. 다시 말해 선언적 패턴은 리액트 방식의 일부이다.

팁: 작업을 처리할 때 ‘프레임워크 방식’을 사용하고 있다면 프레임워크라고 볼 수 있다.

자바스크립트 프레임워크 연혁

제이쿼리

2006년 존 레식이 만든 제이쿼리는 모든 자바스크립트 프레임워크의 모체가 됐다. 오늘날 프론트엔드 개발자들이 제이쿼리를 우습게 여기는 경향이 있지만 제이쿼리는 현대 웹 개발의 초석 역할을 했다.

<aside> 사실 jQuery로 만든 레거시 프로젝트가 너무 많기에 아직까지도 굳건히 순위 안에 들고 있다.
Stack OverflowStack Overflow Developer Survey 2023

앵귤러JS

앵귤러JS는 2009년 미스코 헤브리에 의해 부수적인 프로젝트로 개발됐다. 나중에 그는 구글의 직원이 됐고 이런 이유로 앵귤러JS는 지금은 구글 엔지니어가 관리한다. 1.0 버전은 2011년 5월에 릴리스됐다. 앵귤러JS는 단일 페이지 애플리케이션을 주류로 만드는 데 큰 역할을 했다.

가장 주목할 만한 기능은 양방향 데이터 바인딩이다.

양방향 데이터 바인딩 덕분에 개발자는 웹 애플리케이션을 빠르게 작성할 수 있게 됐다. 그러나 양방향 데이터 바인딩이 대규모 애플리케이션에는 적합하지 않기 때문에 시간이 지나자 많은 개발자가 앵귤러JS를 떠났다.

구글은 앵귤러JS의 단점을 보완하기 위해 앵귤러(앵귤러2)를 출시 했지만 앵귤러JS로 생긴 부정적인 선입견과 아키텍처의 대규모 변화 그리고 높은 러닝커브로 많은 웹개발자들이 Angular대신 React나 Vue를 선택했다. 그러나 구글은 6개월에 한번씩 메이저 버전을 발표하는등 매우 부지런한 행보를 보이고 있다.
릴리즈 정책

리액트

2011년 페이스북에서 만들어 2013년 오픈소스로 공개한 리액트는 현재 가낭 인기 있는 프론트엔드 라이브러리다. 리액트는 선언적 패러다임으로 동작한다. 일반적으로 DOM을 직접 수정하는 대신 setState 메서드로 상태를 변경하면 리액트가 나머지 작업을 수행한다.

기술 부채

프레임워크 비용

미래에 코드 변경이 어렵다는 측면에서 보면 모든 프레임워크가 기술 부채를 갖고있다.
프레임워크는 아키텍처 자체에 이미 비용을 포함하고 있다.
시간이 지남에 따라 시장이나 다른 요인으로 인해 소프트웨어의 변경이 필요하며, 아키텍처 역시 변경돼야한다. 대부분의 경우 프레임워크는 이런 변경이 필요한 상황에서 장애물이 된다.

기술 투자

저자는 프레임워크를 반대하는 것이 이책의 목적은 아니라고 말했다.
기술 부채가 항상 나쁜 것만은 아니다. 중요한 것은 부채 자체가 아니라 부채가 필요한 이유다.
합당한 이유로 선정된 프레임워크는 비용이 아니라 자산이다.
8장에서는 프레임워크가 프로젝트의 자산이 될지 판단하는 데 사용하는 몇 가지 기술적 방법과 ‘비용’이 적게 드는 프레임워클 선택하는 방법을 알아본다.

NextJS는 프레임워크 일까?

NextJS 공식 문서는 웹용 React 프레임워크로 소개하고 있다. 차근차근 NextJS의 제약 조건을 알아보자.

제약 조건(app router 기준)

1. Routing

Next.js 13에서 소개된 app router는 레이아웃, 중첩 라우팅, 로딩 상태, 오류 처리 등을 지원하는 서버 컴포넌트 위에 구축된 파일 시스템 기반 라우터다. 이를 사용하기위해 우리는 NextJS에서 설정한 폴더 구조를 엄격하게 따라야한다

경로의 각 폴더는 경로 세그먼트를 타나낸다. 각 경로 세그먼트는 URL 경로의 해당 세그먼트에 매핑된다.

2. Rendering

NextJS app router는 서버와 클라이언트 컴포넌트를 모두 지원하기 때문에 서버측에서 작동되어야하는 코드와 클라이언트 측에서 작동되어야하는 코드가 구분되어야한다. 이를 해결하기 위해 NextJS는 "use client" , “use server"지시어를 사용한다.

'use client'
 
import { useState } from 'react'
 
export default function Counter() {
  const [count, setCount] = useState(0)
 
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  )
}

클라이언트 컴포넌트 예시

그리고 아래와 같이서버와 클라이언트 컴포넌트를 사용할 때 권장되는 몇 가지 구성 패턴을 다룬다

What do you need to do?	Server Component	Client Component
Fetch data	O	X
Access backend resources (directly)	O	X
Keep sensitive information on the server (access tokens, API keys, etc)	O	X
Keep large dependencies on the server / Reduce client-side JavaScript	O	X
Add interactivity and event listeners (onClick(), onChange(), etc)	X	O
Use State and Lifecycle Effects (useState(), useReducer(), useEffect(), etc)	X	O
Use browser-only APIs	X	O
Use custom hooks that depend on state, effects, or browser-only APIs	X	O
Use https://react.dev/reference/react/Component	X	O

3. Data Fetching

서버 컴포넌트에서 비동기/대기 기능을 통해 데이터 가져오기를 간소화하고 요청 메모화, 데이터 캐싱 및 재검증을 위한 확장된 가져오기 API를 제공한다.

Next.js는 네이티브 fetch Web API를 확장하여 서버에서 각 불러오기 요청에 대한 캐싱 및 재검증 동작을 구성할 수 있다.

async function getData() {
  const res = await fetch('<https://api.example.com/>...')
  // The return value is *not* serialized
  // You can return Date, Map, Set, etc.
 
  if (!res.ok) {
    // This will activate the closest `error.js` Error Boundary
    throw new Error('Failed to fetch data')
  }
 
  return res.json()
}
 
export default async function Page() {
  const data = await getData()
 
  return
 }

4. Optimizations

Next.js에는 애플리케이션의 속도와 핵심 Web Vitals을 개선하기 위해 설계된 다양한 최적화 기능이 내장되어 있다. 대표적인 예로 Next.js 이미지 컴포넌트는 자동 이미지 최적화를 위한 기능으로 HTML <img> 요소를 확장한 Image 컴포넌트 사용을 권장한다.

import Image from 'next/image'
import profilePic from './me.png'
 
export default function Page() {
  return (
    <Image
      src={profilePic}
      alt="Picture of the author"
      // width={500} automatically provided
      // height={500} automatically provided
      // blurDataURL="data:..." automatically provided
      // placeholder="blur" // Optional blur-up while loading
    />
  )
}

저자의 시점에서 본다면 NextJS는 프로젝트 시작부터 끝까지 강한 제약들이 존재한다. 웹 개발의 선두를 달리고 있지만 과연 5년뒤에도 NextJS가 추구하는 아키텍처, 폴더 구조들이 변하지 않는다고 장담 할 수 있을까? 지금까지 나는 프로젝트 시작부터 매우 큰 부채를 떠안고 시작한게 아닌가 싶다. 앞으로 스터디를 진행하면서 우리가 사용하는 프레임워크가 프로젝트의 자산이 될지 판단하는 방법을 터득할 생각에 기대가 된다.

참고:

개발자를 넘어 기술 리더로 가는 길 - 타냐 라일리

_OIL — Sat, 15 Jun 2024 23:05:59 +0900

I'm Okay I'm Fine 괜찮아 괜찮아 댕랭랭랭레~

근래에 일을 하는 이유와 현 경력 지속 여부 그리고 돈을 버는 이유와 행복의 기준이 무엇인지 재 정립이 필요하다고 느끼는 와중에 개발자를 넘어 기술 리더로 가는 길을 접하니 챌린지만 늘어나고 머리만 복잡해졌다. 복잡한 생각을 횡설수설 말해 의미 전달도 제대로 안되고 책 주제를 너무 벗어나게 될 거 같아 심히 걱정이 된다. 그래서 이번에는 온전히 듣고 질문하는 것만 목표로 해보고 싶다.

현실과 책 내용의 간극이 커서 인지 부조화가 왔고 내용에 집중을 못 했다. 그래도 개발 언더독 생활을 하면서 스쳐 지나갔던 프로젝트들이 실패한 이유 중 하나가 기술 리더가 없었기 때문이라는 걸 확실하게 인지했다. 부끄럽게도 책을 읽기 전까지 매니저(PM)와 기술 리더(스태프 엔지니어)의 차이를 잘 알지 못했었다. 나름의 변명을 해보자면 우리나라의 대부분의 회사들은 조직 내에서 상대적으로 경력이 많은 개발자에게 매니저와 기술 리더의 역할을 동시에 부여하고 있는 게 아닌가 싶다. 설령 매니저 와 기술 리더가 직책상 나눠져 있어도 그 의미를 제대로 알고 알고 수행하는 사람은 몇 없을 거라 생각한다.

저자는 기술 리더의 자격으로 '다양한 기술적 지식과 풍부한 경험'이 기반되어 '빅 픽처 관점의 사고력'과 '성공적인 프로젝트 실행력'그리고 '조직 차원의 레벨 업' 이라는 영향력이 뒷받침되어야한다고 말한다. 어려워도 너무 어렵다. 솔직히 말해서 이 분야에서 20~30년 더 일한다고 해서 저런 자격을 갖춘 그릇이 될거 같지는 않다. 그래도 책 소개 글에 있는

"스태프 엔지니어가 되고 싶은가? 더 높은 기술자 직급을 열망하지 않아도 괜찮다. 매니저 진로로 이직하거나(또는 왔다 갔다 하는 것) 좋아하는 일을 계속하면서 시니어 레벨에 머무르는 것도 좋다. 어떤 상태이든 여러분이 조직의 목표를 달성하는 것을 돕고 주변 엔지니어들의 실력을 향상시키면서 기술적인 역량을 계속해서 구축하고자 한다면, 이 책을 계속 읽어보기를 바란다."

라는 문구가 끝까지 책을 읽을 수 있는 원동력이 되었던거 같다.

마지막으로 책을 읽으면서 알 수 없는 언짢음이 지속적으로 올라왔다. 감정의 원인을 생각해 보니 너무 많은 책임을 요구해 시작도 전에 지레 겁을 먹은 거 같다. 책에서 제시하는 일들을 즐기면서 할 수 있을까? 내 그릇을 키우려면 앞으로 더 큰 도전들을 수행해야 되는데 버겁지 않을까? 쓸데없는 고민은 그만하고 긍정적으로 생각하며 마무리한다.

혼자 힘으로 할 수 있는 것은 극히 제한적이다.
어떻게든 속한 조직의 자원과 인력을 최대로 활용해 최고의 결과를 도출해야된다.
배척대신 서로의 부족함을 인정하고 채워줘야한다.
컴퓨터와 일하는게 아니라 사람과 일하는 것이다.
협력은 배려로 부터 시작된다.
균형은 누군가 만들어주는 것이 아니라 스스로 만드는 것이다.

책에서 와닿았던 문구를 정리하면 아래와 같다.

너무 많은 사이드 업무와 도움에 휘말릴수록 여러분이 정말로 책임져야 할 일을 할 시간이 없어진다. 분별력을 가져라! -401
코드를 작성하는 것은 소프트웨어 엔지니어링의 한 단계일 뿐이다. -198
상사에게 보고한다는 것은 다른 팀에 관해서 불평한다거나 조직 내에서 소란을 일으키는 행위가 아니다. 그보다는 여러분을 도와줄 힘이 있는 사람과 정중하게 대화를 나누고, 함께 문제를 해결하려는 것을 의미한다. -223
여러분의 계획 부족이 저희의 비상사태는 아닙니다. -227
엔지니어링은 컴퓨터 시스템과 소통하는 수준에서 끝나는 것이 아니라 이는 여러분이 타인과 이야기하는 방식과 관련이 있다. -259
엔지니어로서 확고하게 고참 자리에 오르기 전에는 절대로 매니저 역할을 맡지 말아라. 나에게 이것은 적어도 7년 이상의 코드 작성과 배포 경력을 갖추는 것을 의미한다 -262

맥킨지는 일하는 방식이 다르다 - 에단 라지엘

_OIL — Sun, 5 May 2024 20:32:51 +0900

일잘러의 3가지 접근 방식

우리가 일을 하다 보면 매일 문제를 발견하고 해결해야 된다. 이는 모든 직군이 가치 있는 것을 생산하기 위해 어떠한 형태로든 행해야 된다. 몇 년 일을 해보니 나만의 문제 해결 방식에 대한 노하우가 쌓였지만 의식적으로 내 방법들이 올바르게 형성된 것인지는 검증하진 않았다. 책을 읽으면서 다른 부분은 조율하고 몰랐던 부분은 수용하고 같은 부분은 어느 정도는 일을 잘하고 있었다는 안도감 얻을 수 있어서 시간이 아깝지 않았었다.

1부 문제 해결 방식

맥킨지는 사실에 근거하기, 구조화 하기, 가설을 수립하고 접근 하기를 통해 문제에 대한 해결책을 도모한다.

문제의 크기에 압도되거나 경험이 전무한 프로젝트에 투입되는 경우에 3가지의 접근 방식을 놓쳐 간단한 문제조차도 오랜 시간 허비하거나 심한 경우 프로젝트가 망가지는 것도 보았다. 현재까지는 프로젝트 결과에 대한 책임이 적은 위치에 있었기에 반면교사로 삼을 뿐이지만 언제든 큰 책임과 역할을 요구할 수 있기에 작은 문제가 발생해도 3가지 태도를 의식적으로 유지한다.

어떤 비즈니스 문제도 동일한것은 없다

나의 업무 스타일은 예스맨에 가까운데 그 이유는 새로운 요구사항이나 문제가 들어올 때 이전에 비슷한 경험을 해본 경우가 있다면 동일한 접근 방식을 적용해 빠르게 해결할 수 있을 거 같기 때문이다. 그래서 '기간 내에 할 수 있어요' 또는 '10~15분 정도 걸릴 거예요'를 하루에도 2~5번 정도 남발한다. 물론 같이 협업하는 기획자나 디자이너들은 이 태도를 반기지만 의도치 않게 완전히 다른 접근 방식을 요구하는 문제라서 일정이 연장된다면 동료 개발자에게 허세만 가득한 개발자가 되는 위험 부담이 있다. 마치 김민재 선수가 예측 수비를 성공하면 최고의 센터 백이 되는 것이지만 실패하면 팀에 실점을 안기는 양날과 같은 행동이다. 그래서 최상의 해결책을 찾기 위해 각각의 문제에 어떻게 접근해야 하는지를 소개하는 책의 소 제목들이 인상 깊었다.

파벌 싸움을 극복하라

개발자는 회사 내의 파벌 싸움에 큰 영향이 없을 거라 생각했는데 이 생각은 근래에 프리랜서를 한지 2개월 만에 바뀌었다. 그럼에도 문제를 풀어야 한다면 컨설턴트가 아닌 개발자로서 어떤 태도를 취해야 될지 고민이 많은 상황이다.

2부 업무수행 방식

프로젝트 수주

직접 영업을 하는 것이 아니라 컨설팅을 원하는 기업들이 맥킨지에 전화하도록 다양한 출판물과 자선단체 같은 외부 활동을 장려해 고객이 스스로 방문하는 환경을 구축하는 방식은 본받을만하다. 동일하게 적용해 본다면 취업하기 위해 면접을 보는 것이 아니라 내 경험을 다양한 곳에 공유하고 다양한 온, 오프라인 개발자 커뮤니티 참여는 더 많은 기회를 얻을 것이라 본다. 이러한 방식을 통해 좋은 선례를 남긴 멤버가 있다면 더 자세한 이야기를 들어보고 싶다.

팀 - 그들과 직접 만나서 얘기를 나눠라

맥킨지의 팀은 세계 최고의 구성원들만 모인 곳이라 내가 있는 세계와 비교했을 때는 매우 비 현실 적다. 하지만 팀을 구성하고 관리할 때 팀원을 이하기 위해 직접 만나서 대화를 나누는 방법은마음속 깊은 곳에 보관해야 되겠다.

3부 커뮤니케이션 방식

구조화하라

상대방에게 알기 쉬운 방식으로 논리를 전개하는 사람은 그 자체로 매우 똑똑하고 배려 깊은 사람인 거 같다. 최근에 RESTful 하지 못한 api를 받아봤는데 내색하진 않았지만 해당 api를 만든 개발자가 경력이 월등히 많았음에도 불구하고 신뢰가 완전히 사라져 버렸다.

정보가 계속 흐르게 하라

전 회사에서는 동료들끼리 새로운 기술이나 사용하고 있는 언어의 동향을 자연스럽게 나누는 문화가 있었는데 그때 자연스럽게 나눴던 정보들이 문제 해결에 중요한 키가 된 경우가 많았었다.

고객 팀과 함께 일하는 것에 대하여

자신의 회사가 아닌 고객의 회사에 들어가 업무를 본다는 것은 정말 많은 눈치를 보는 일이라 생각한다. 행동 하나하나가 조심스러워지고 작은 발언이 월권이 되지 않을까 노심 초사한다. 특히 책의 일화 중 주도해서 만든 프로젝트의 공로를 고객 팀의 팀원들이 뺏어갔을 때 분노하지 않고 그들의 모델이 되도록 수용한 것도 전문가적인 마인드로 본받고 싶다.

마치며,

앞으로 향후 5년 이내로 개발자를 계속할 수 있을지는 의문이다. 하지만 사회 구성원으로서 문제를 해결하고 가치를 생산하는 일을 좋아하기 때문에 그리고 그러한 행위를 통해 돈을 (효율적으로 많이) 버는 것을 좋아하기 때문에 어떤 형태로든 일을 할 것이다. 누군가 나에게 어떤 가치관으로 일을 하고 있냐고 물어본다면 맥킨지스럽게 일하는 것을 추구한다고 말해봐야 되겠다.

소프트 스킬 - 존 손메즈

_OIL — Sat, 30 Mar 2024 22:19:21 +0900

용두사미

소프트웨어 개발자가 아니어도 갓 사회에 입문하거나 멘토가 없다고 느끼는 사람들에게 추천해 주면 괜찮은 책이라 생각한다. 서문을 읽고 책의 내용들이 기대가 되었다. 저자는 살아남기 위해 치열하게 삶을 살아왔고 자신이 고생해서 얻은 노하우를 알려줄 테니 당신은 그런 고통을 덜 받으면 좋겠다는 뉘앙스가 든든한 선배를 얻은듯한 느낌이다. 그가 적은 글귀들을 훑을 때는 아무나 할 수 있는 것이지만 지속적으로 할 수 있는 부류는 이미 상위 분포에 위치한 사람들이 아닐까 싶다.

Part 1경력
자신의 경력을 사업으로 봐야 한다는 말이 이해가 되었고 실천 중이라면 굳이 이 책을 볼 필요가 있을까 싶다. 그래도 각각의 챕터들이 일에 대한 생각을 설정하기 좋은 내용들이라 생각날 때마다 찾아보면 인생을 더 쪼을 수 있어 보인다.

Part 2 셀프 마케팅
재야의 숨은 고수들이라면 누군가 찾지 않아도 자신의 존재를 빛내겠지만 평범 또는 그 이하일 수 있는 개발자인 나는 셀프 마케팅이 이 험악한 세상에서 굶어 죽지 않고 살아나갈 수 있는 방법이 아닌가 싶다. 물론 블로그나 유튜브, 트위터, 강연 활동을 하고 있지 않지만 회사, 동아리 활동, 스터디 모임 등 내가 속한 작은 사회에서 신뢰를 쌓는 것도 셀프 마케팅의 근간이라 생각한다. 그리고 이러한 것이 누적되어 새로운 일이 트이거나 인연이 생긴다면 그것만으로도 인생의 즐거움을 충족 시켜주는 요소라 생각한다.

Part 3 학습, Part4 생산성
딱히 할 말이 없다. 조금 비뚤어진 시선으로 보면 성공한 사람들이 자기 계발서를 쓰면 항상 보이는 레퍼토리라 생각한다. 자기 계발서를 몇 권 읽어본 독자들이라면 이 파트부터 지겨움을 느꼈을 거 같다.

Part 5 재무관리, Part6 건강, Part7 마이드셋
조금은 전문성이 떨어지는 부분이기도 하고 저자가 공유해 준 내용들이 유명한 자기 계발서에서 뽑아온 내용들이다. 이미 그러한 책들은 읽고 부분적으로 적용해 본 경험이 있어 크게 와닿지 않았다. 그래도 저자가 독자들에 대한 애정이 넘친다고 생각했다.

시작은 좋았지만 끝은 미약했다. 책을 다 읽었을 때는 저자의 상술에 당한 느낌도 들었다. (나로 인해 저자는 저작권료를 벌었구나..) 항상 이러한 종류의 자기 계발서를 읽을 때마다 생기는 감정 같다. 누구나 할 수는 있지만 지속하기는 어려운 행위들, 안쓰러움 반 존경 반, 허탈함 반 감사함 반

테크 커리어 - 돈 존스

_OIL — Sat, 30 Mar 2024 22:14:00 +0900

Own Your Life

책 도입 부분에서 저자는 잠시 멈춰서 자신이 원하는 인생(성공)을 정의하라고 권한다. 그래야 무턱대고 더 많은 것을 얻기 위한 무한 경쟁에 휩쓸리지 않고 자신의 인생을 주도적으로 이끌 수 있음을 강조한다. 하지만 나는 시간이 없기에 성공의 정의를 머릿속으로 1분 정도 짧게 정의하고 페이지를 넘기다 보니 저자가 말하는 대로 행하는 것이 과연 나한테 무슨 의미가 있는지 괴리감을 빈번하게 느꼈다. 완독을 하고 내가 해야 할 것은 도입 부분에 있던 내 인생 그리고 내가 생각하는 성공을 재정의 해보는 것이었다.

내가 살고 싶은 인생은 어떤 인생인가?

일을 할 때 그리고 하지 않을 때 어떻게 시간을 보내고 싶은가?

세상에는 어떻게 기여하고 싶은가?

하고 싶은 취미나 경험은 무엇인가?

예전에는 위와 같은 질문들을 만나면 고민 없이 답이 나왔는데 요즘은 질문 하나하나가 무겁게 다가온다. 그저 쉼이 부족해서 그런 걸까? 모임을 통해 많은 사람의 이야기를 듣고 이야기 속에 투영된 나 자신도 되돌아볼 수 있는 시간이 되면 좋겠다.

역자의 서문에서 책의 원서 제목이 Own Your Tech Carrer(자신의 기술 경력은 자신이 소유하라)이라고 알려줬다. 조금 더 확대 해석해보면 저자가 열성을 다해 우리에게 전달하려는 의미가 자신의 삶을 원하는 대로 제어 할 수 있을 때 오는 기쁨을 알려 주고 싶어서 저자만의 방법으로 표출한 게 아닐까? 라는 생각이 잠깐 스쳤다.

나중에 일을 진정으로 하고 싶어지고 경력에 대해 몸과 마음이 열렸을 때 목차 부분만 다시 한번 훑어 봐야 되겠다.

NextJS next-redux-wrapper hydrate 버그 수정

_OIL — Sun, 31 Dec 2023 19:28:26 +0900

next-redux-wrappe 공식 문서에서 next js에서 store를 관리하는 방법 2가지를 소개합니다.

그중 2번째 방법을 사용하고 있었는데 아마도 초기 리덕스 설정을 할 때 _app.tsx에 wrapper.getInitialAppProps를 사용하면 자동적으로 서버와 클라이언트 store를 관리해 주는 것으로 착각한 거 같습니다. 즉, 지금까지 의미 없는 서버 쪽 store를 호출해 hydrate를 계속 발생시키고 있었던 겁니다. 서버 쪽에서 의미 없는 hydrate를 계속 발생시키니 rootReducer코드를 보면 서버가 보내는 action.payload에 store의 초기값이 담겨 오므로 클라이언트의 store가 계속 초기화되는 것입니다.

const rootReducer = (state: any, action: any) => {
  switch (action.type) {
    case HYDRATE:
      return { ...state, ...action.payload };

클라이언트의 store가 계속 초기화 되서 각 페이지마다 이용 서비스를 체크하는 saga(api 통신 후 전역스토어에 저장해 주는 역할)를 호출하지 않으면 전역 store에 관리되고 있는 menu가 초기화되므로 사이드바의 메뉴 필터가 정상적으로 작동하지 않는 문제가 생깁니다.

문제 해결을 위한 2가지 방법

wrapper.getInitialAppProps으로 감싸져 있으니 서버쪽에서 서비스를 체크하는 api를 호출한 후 menu의 전역 상태값을 넣어주자

이 방법은 페이지를 이동할때마다 중복 api가 호출됩니다. 클라이언트 호출에서 서버 호출로 바뀐 것뿐 근본적인 문제가 해결되지 않습니다. 또한 menu 말고 다른 전역 상태값들도 신경 써야 되므로 매우 비효율적이고 광범위한 작업이 됩니다. 2. wrapper.getInitialAppProps를 지워 의미 없는 HYDRATE를 방지하자! getInitialProps는 nextjs에서 지양하는 방법이기도 하고 굳이 여기서 서버 쪽 store를 호출해 HYDRATE를 발생시켜 스토어를 초기화시킬 이유가 없습니다.

따라서 2번 방법을 적용합니다.

참고 문서: next-redux-wrapper

Routing - Pages and Layouts

_OIL — Tue, 17 Oct 2023 00:13:44 +0900

페이지 라우터는 페이지 개념을 기반으로 구축된 파일 시스템 기반 라우터입니다.

파일이 페이지 디렉터리에 추가되면 자동으로 경로로 사용할 수 있습니다.

Index routes

라우터는 index라는 이름의 파일을 디렉터리의 루트로 자동 라우팅합니다.

pages/index.js → /
pages/blog/index.js → /blog

Nested routes

라우터는 중첩 파일을 지원합니다. 중첩된 폴더 구조를 만들면 파일은 여전히 동일한 방식으로 자동으로 라우팅 됩니다.

pages/blog/first-post.js → /blog/first-post
pages/dashboard/settings/username.js → /dashboard/settings/username

Pages with Dynamic Routes

Next.js는 동적 경로가 있는 페이지를 지원합니다. 예를 들어 pages/posts/[id]. js라는 파일을 만들면 posts/1, posts/2 등에서 액세스 할 수 있습니다.

Layout Pattern

React 모델을 사용하면 페이지를 일련의 컴포넌트로 분해할 수 있습니다. 이러한 컴포넌트 중 상당수는 페이지 간에 재사용되는 경우가 많습니다. 예를 들어 모든 페이지에 동일한 navigation bar와 footer가 있을 수 있습니다.

import Navbar from './navbar'
import Footer from './footer'

export default function Layout({ children }) {
  return (
    <>
      <Navbar />
      <main>{children}</main>
      <Footer />
    </>
  )
}

Examples

Single Shared Layout with Custom App

전체 애플리케이션에 레이아웃이 하나만 있는 경우 재사용될 <Layout /> 컴포넌트를 만들어 애플리케이션 전체를 래핑 합니다.

import Layout from '../components/layout'

export default function MyApp({ Component, pageProps }) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  )
}

Per-Page Layouts(페이지별 레이아웃)

여러 레이아웃이 필요한 경우, 페이지에 getLayout 속성을 추가하여 레이아웃에 대한 React 컴포넌트를 반환할 수 있습니다. 이를 통해 페이지 단위로 레이아웃을 정의할 수 있습니다. 함수를 반환하기 때문에 원하는 경우 복잡한 중첩 레이아웃을 가질 수 있습니다.

import type { ReactElement } from "react";
import Layout from "@/components/Layout";
import NestedLayout from "@/components/NestedLayout";
import { NextPageWithLayout } from "@/pages/_app";

const Page: NextPageWithLayout = () => {
  return <div className="bg-amber-600">본문</div>;
};

Page.getLayout = function getLayout(page: ReactElement) {
  return (
    <Layout>
	    <NestedLayout>{page}</NestedLayout>
    </Layout>
  );
};

export default Page;

import type { ReactElement, ReactNode } from "react";
import type { NextPage } from "next";
import type { AppProps } from "next/app";
import "../styles/globlas.css";

export type NextPageWithLayout<P = {}, IP = P> = NextPage<P, IP> & {
  getLayout?: (page: ReactElement) => ReactNode;
};

type AppPropsWithLayout = AppProps & {
  Component: NextPageWithLayout;
};

export default function MyApp({ Component, pageProps }: AppPropsWithLayout) {
  // Use the layout defined at the page level, if available
  const getLayout = Component.getLayout ?? ((page) => page);

  return getLayout(<Component {...pageProps} />);
}

페이지 사이를 탐색할 때 SPA(단일 페이지 애플리케이션) 경험을 위해 페이지 상태(입력 값, 스크롤 위치 등)를 유지하려고 합니다. 이 레이아웃 패턴은 페이지 전환 사이에 React 컴포넌트 트리가 유지되기 때문에 상태 지속성을 가능하게 합니다. 컴포넌트 트리를 통해 React는 상태를 유지하기 위해 어떤 요소가 변경되었는지 파악할 수 있습니다.

상세 설명

1. `NextPageWithLayout` 타입 정의:

export type NextPageWithLayout<P = {}, IP = P> = NextPage<P,IP> & {
	getLayout?: (page: ReactElement) => ReactNode;
};

- `NextPageWithLayout`는 `NextPage`의 확장된 타입입니다. 이 타입은 페이지 컴포넌트에 레이아웃을 적용하는 데 사용됩니다.
- `getLayout`은 페이지 컴포넌트에서 레이아웃을 정의할 때 사용할 수 있는 함수입니다.

2. `AppPropsWithLayout` 타입 정의:

type AppPropsWithLayout = AppProps & {
	Component: NextPageWithLayout;
};

- `AppPropsWithLayout`는 앱의 props에 페이지 컴포넌트와 레이아웃을 관리하기 위한 확장된 타입입니다. `Component` 속성은 `NextPageWithLayout` 유형을 가지고 있습니다.

3. `MyApp` 컴포넌트:

export default function MyApp({ Component, pageProps }: AppPropsWithLayout) {
	// Use the layout defined at the page level, if available
	const getLayout = Component.getLayout ?? ((page) => page);
	return getLayout(<Component {...pageProps} />);
}

- `MyApp` 컴포넌트는 앱의 메인 컴포넌트로 사용됩니다.
- `Component`는 현재 페이지 컴포넌트를 나타냅니다.
- `pageProps`는 현재 페이지 컴포넌트의 프롭스(props)입니다.
- `Component.getLayout`은 페이지 컴포넌트에서 정의한 레이아웃 함수입니다. 페이지 컴포넌트가 이 함수를 정의한 경우 페이지 컴포넌트의 레이아웃 함수가 사용됩니다. 그렇지 않으면 기본적으로 페이지 컴포넌트 자체가 레이아웃으로 사용됩니다.
- 마지막으로, `getLayout` 함수를 사용하여 현재 페이지 컴포넌트와 프롭스를 레이아웃 함수에 전달하고, 레이아웃 된 페이지를 반환합니다.

이렇게 설정된 `MyApp` 컴포넌트는 전역적으로 페이지 컴포넌트에 레이아웃을 적용하는 데 사용됩니다. 페이지 컴포넌트에서 레이아웃 함수를 정의하면 해당 레이아웃이 페이지에 적용되며, 그렇지 않으면 페이지 컴포넌트 자체가 레이아웃으로 사용됩니다.

❓ 중첩 레이아웃을 사용하면 상태값이 유지되는 이유는 뭘까요?

레이아웃 변경은 페이지의 일부 컴포넌트 트리를 변경하므로 React는 레이아웃 변경에 따라 최소한의 DOM 조정만 수행할 것입니다.

예를 들어, 헤더, 사이드바 및 메인 콘텐츠로 구성된 레이아웃을 가진 페이지를 생각해 보십시오. 사용자가 이 페이지를 다른 페이지로 이동할 때, React는 현재 페이지와 새 페이지 간의 레이아웃 변경에 따라 레이아웃을 효율적으로 조정합니다. 새로운 페이지의 레이아웃이 이전 페이지와 다른 경우, React는 필요한 변경만 DOM에 반영하며 이러한 변경은 reconciliation 프로세스를 통해 관리됩니다.

요약하면, Next.js의 per-page layout를 사용하면 각 페이지에 대해 사용자 정의 레이아웃을 정의할 수 있으며, React의 reconciliation 프로세스는 이러한 레이아웃 변경을 효율적으로 관리하고 렌더링 성능을 최적화합니다.

[state 보존 및 재설정] 참고

그래서 [nextjs-nested-layout-pages-dir]의 dashboard하위의 페이지들이 고유의 레이아웃을 만들어도 인풋의 입력값이 유지되는 것을 볼 수 있습니다.

Per-page layout pattern이 생긴 배경

부제: 왜 getLayout은 함수여야 할까?

참고 블로그 링크: https://adamwathan.me/2019/10/17/persistent-layout-patterns-in-nextjs/ (저자: Adam Wathan-tailwindCSS 만든 사람)

React, Angular, Vue와 같은 SPA의 가장 큰 장점 중 하나는 페이지 이동 시에도 전체 문서를 처음부터 다시 렌더링 하지 않고도 사이트를 탐색할 수 있다는 점이었습니다. 왜냐면 페이지를 새로 받아와 렌더링 하는 것이 아니기 때문이죠.

즉, 스크롤 위치를 저장하고 다음 페이지 이동 시 스크롤 위치를 복원하는 복잡한 작업 없이도 사이드바 컴포넌트처럼 변경되지 않는 UI부분의 스크롤 위치를 보존하는 등의 작업을 수행할 수 있습니다.

그러나 NextJs를 사용해 보면 Link를 통해 페이지 이동시 전체 화면을 처음부터 다시 렌더링 한다는 것을 알 수 있습니다. 그렇다면 NextJs는 페이지 이동시에도 변하지 않는 UI의 상태값을 유지하기 위해 어떤 방법을 시도해왔을까요?

위 프로젝트는 크게 두 가지 섹션으로 구성되어 있습니다:

홈 화면은 한 페이지로 구성되어 있습니다.
가로로 스크롤할 수 있는 탭 목록이 포함된 account-settings 섹션으로, 이 섹션을 클릭하면 다른 하위 섹션으로 이동할 수 있습니다.

위 데모에서는 페이지에 필요한 레이아웃 구성 요소를 각 페이지마다 동일하게 넣어주고 있습니다. 이 접근 방식의 문제점은 account-settings 페이지 중 하나를 방문하여 탭 목록을 오른쪽 끝까지 스크롤한 다음 'Security' 탭을 클릭하면 페이지가 이동되면서 탭의 가로 스크롤이 왼쪽 끝으로 초기화됩니다.

분명 reconciliation개념에 따라 동일한 component tree를 갖고 있으면 스크롤 위치 같은 상태값이 유지되어야 하는데 뭔가 이상합니다.

사실 각 페이지의 가장 상위 component는 우리가 보고 있는 그 SiteLayout가 아니라 바로 _app.js파일에 전달되는 props 중에 Component(Page component)입니다. 페이지 이동시 Page component가 바뀌므로(가장 최상위 component가 바뀌므로) React는 모든 children을 버리고 처음부터 다시 그리게 됩니다. 즉, 이전 페이지에서 이미 DOM의 같은 위치에 해당 컴포넌트를 렌더링 했더라도 각 페이지가 SiteLayout 또는 AccountSettingsLayout의 새로운 복사본을 렌더링 합니다.

그래서 NextJs에서 위 데모처럼 코드를 짜면 서버 기반 애플리케이션 UI처럼 느껴지는 단일 페이지 애플리케이션이 돼버립니다. 으악!

방법 1: 사용자 지정 <App> 컴포넌트에서 단일 공유 레이아웃(single shared layout) 사용

사이트에 persistent layout component를 추가하는 한 가지 방법은 custom App component를 만들고 컴포넌트 트리에서 항상 현재 Page component 위에 사이트 레이아웃을 렌더링 하는 것입니다.

import SiteLayout from '../components/SiteLayout'

export default function MyApp({ Component, pageProps }) {
  return (
    <SiteLayout>
      <Component {...pageProps} />
    </SiteLayout>
  )
}

SiteLayout 컴포넌트는 페이지 전환 시 재사용되므로 검색 필드에 입력한 내용이 그대로 유지됩니다.

하지만 AccountSettingLayout처럼 일부 페이지에서 공유하는 추가적인 Layout이 있다면? Account setting의 하위 페이지들은 AccountSettingLayout을 사용해야 됩니다. 그리고 AccountSettingLayout는 가로 스크롤이 있는 tab bar를 포함하고 있습니다. AccountSettingLayout은 App component에 포함되어있지 않기 때문에 tab bar의 scroll 위치를 기억할 수 없습니다.

방법 2: 현재 URL을 기반으로 <App>에서 다른 레이아웃 렌더링하기

단일 공유 레이아웃(single shared layout)으로 가능한 것보다 요구 사항이 약간 더 복잡하다면 현재 URL을 기반으로 다른 트리를 렌더링 하는 것으로 해결할 수 있습니다.

router.pathname을 검사하여 현재 사이트의 어느 'section'에 있는지 파악하고 해당 레이아웃 트리를 렌더링 할 수 있습니다:

class MyApp extends App {
  render() {
    const { Component, pageProps, router } = this.props
    if (router.pathname.startsWith('/account-settings/')) {
      return (
        <SiteLayout>
          <AccountSettingsLayout>
            <Component {...pageProps}></Component>
          </AccountSettingsLayout>
        </SiteLayout>
      )
    }
    return (
      <SiteLayout>
        <Component {...pageProps}></Component>
      </SiteLayout>
    )
  }
}

이 경우, /account-settings/ 아래 페이지들은 같은 layout component tree를 공유할 수 있고 따라서 SiteLayout 뿐 아니라 AccountSettingsLayout 역시 재 사용 되어 페이지 이동을 하더라도 상태를 유지할 수 있습니다.

이 접근 방식의 단점은 각 페이지 component 별로 어떤 Layout을 사용하는지 Page 파일만 봐서는 알기 어려운 문제점이 있으며

레이아웃을 URL에 연결하기 때문에 레이아웃을 변경해야 하는 경우(예: /account-settings/delete가 완전히 다른 레이아웃을 사용하는 경우) 매우 구체적인 조건부 로직을 점점 더 많이 추가해야 합니다.

따라서 소규모 사이트에서는 이 방법이 효과적일 수 있지만, 대규모 사이트에서는 좀 더 선언적이고 유연한 방법이 필요할 것입니다.

방법 3: Page component에 정적 'layout' 속성 추가하기

시간이 지남에 따라 앱 컴포넌트의 복잡성이 증가하는 것을 방지하는 한 가지 방법은 페이지 레이아웃을 정의하는 책임을 앱 컴포넌트가 아닌 페이지 컴포넌트로 옮기는 것입니다.

각 Page Component가 export 하는 page component 객체에 ‘layout’이라는 property를 추가하고 그 layout property를 앱 컴포넌트 내부에서 읽어주면 됩니다 대신 Layout component를 중첩해 선언할 수는 없기 때문에, 이 경우 중첩된 Layout을 담는 하나의 새로운 Layout이 필요합니다:

//components/AccountSettingsLayout.jsx
const AccountSettingsLayout = () => <SiteLayout>{/* ... */}</SiteLayout>

export default AccountSettingsLayout

// /pages/account-settings/basic-information.js
import AccountSettingsLayout from '../../components/AccountSettingsLayout'

const AccountSettingsBasicInformation = () => <div>{/* ... */}</div>

AccountSettingsBasicInformation.layout = AccountSettingsLayout

export default AccountSettingsBasicInformation

import React from 'react'
import App from 'next/app'

class MyApp extends App {
  render() {
    const { Component, pageProps } = this.props
    const Layout = Component.layout || (children => <>{children}</>)
    return (
      <Layout>
        <Component {...pageProps}></Component>
      </Layout>
    )
  }
}
export default MyApp

이 방법은 완벽해 보이지만 한 가지 문제가 있습니다. SiteLayout의 state가 보존되지 않습니다.

그 이유는 이 예제에서 AccountSettingsLayout이 내부적으로 SiteLayout을 사용하기 때문에 실제 최상위 레이아웃 컴포넌트가 SiteLayout에서 AccountSettingsLayout으로 전환되고 원래 있던 SiteLayout이 파괴되고 AccountSettingsLayout 내부에서 생성된 새 SiteLayout 인스턴스로 대체되기 때문입니다.

즉, SiteLayout을 layout으로 쓰는 페이지에서 AccountSettingsLayout을 layout으로 쓰는 페이지로 이동할 경우, react 관점에서 최상의 component가 바뀌는 것이므로 새롭게 SiteLayout instance를 생성합니다.

방법 4: Page component에 getLayout 함수 추가하기

단순한 layout 프로퍼티 대신 정적 함수를 사용하면 복잡한 레이아웃 트리를 반환할 수 있습니다:

// /pages/account-settings/basic-information.js

import SiteLayout from '../../components/SiteLayout'
import AccountSettingsLayout from '../../components/AccountSettingsLayout'
const AccountSettingsBasicInformation = () => <div>{/* ... */}</div>

AccountSettingsBasicInformation.getLayout = page => (
	<SiteLayout>
		<AccountSettingsLayout>{page}</AccountSettingsLayout>
	</SiteLayout>
)

export default AccountSettingsBasicInformation

그런 다음 _app.js에서 현재 페이지에 전달된 함수를 호출하여 전체 트리를 가져올 수 있습니다:

// /pages/_app.js
import React from 'react'
import App from 'next/app'

class MyApp extends App {
	render() {
		const { Component, pageProps, router } = this.props
		const getLayout = Component.getLayout || (page => page)
		return getLayout(<Component {...pageProps}></Component>)
	}
}
export default MyApp

(이 예제에서는 getLayout이라는 이름을 사용했지만, 프레임워크 기능이나 다른 어떤 것이든 원하는 대로 사용할 수 있습니다).

이렇게 하면 각 페이지 컴포넌트가 전체 레이아웃을 담당하고 임의의 수준의 UI 지속성을 허용합니다:

노션에서 옵시디언으로 전환하기

_OIL — Thu, 5 Oct 2023 23:38:34 +0900

노션에서 옵시디언으로 옮기는 이유

옵시디언의 장점과 옵시디언 vs노션을 비교하는 자료들은 찾아보면 많기 때문에 길게 풀어놓지는 않겠습니다. 노션과 옵시디언 비교 글, 옵시디언과 노션의 비교 유뷰트, 노매드 코더의 옵시디언 소개 유튜브 , 옵시디언 고수의 블로그

개인적으로 노션을 이용해 다양한 글 & 자료 & 일정을 관리하고 있지만 페이지의 용량이 늘어날수록 느려지는 속도, 정규화된 템플릿으로 커스텀에 제한이 많음, 슬슬 물리기 시작하는 노션의 UI 등으로 인해 지속적으로 노션을 대체할 만한 앱을 둘러보고 있었습니다. 많은 대체 앱들 중 옵시디언을 선택한 이유는 바로 아래와 같은 멋진 그래프 때문이죠

위 그래프는 내 개인 노션에 있는 글들을 옵시디언으로 옮겼을때 어떤 글들이 어떻게 관계를 갖고 있는지 그래프로 표현해준 것입니다. 아직은 옵시디언에 최적화가 안되었기 때문에 비교적 단순한 그래프이지만 말 그대로 옵시디언을 이용해 글을 작성하면 제2의 두뇌를 눈으로 볼 수 있습니다. 하나에 꽂히면 계획한 일정은 저~뒤로 미루는 편이라 이번 추석 연휴의 이틀을 옵시디언을 갖고 노는 데 사용했어요 그래도 여러 삽질 끝에 옵시디언을 어떻게 사용하면 좋을지 두각이 잡혔기 때문에 느낀 점을 글로 남겨봅니다.

옵시디언을 이용해 해보고 싶었던 것

노션에 있는 글들을 모두 옵시디언으로 옮겨 멋진 그래프를 본다
옵시디언에 작성된 글들은 자동으로 Github의 특정 repository 백업되어 내가 사용하고 있는 기기(개인 맥북, 회사 맥북, 아이폰, 아이패드)들에 동기화되어야 한다.
- 옵시디언은 동기화를 위한 유료 서비스를 제공하지만 요금이 월 10달러라 과감히 포기
- remotely save커스텀 플러그인을 사용해 ICould, dDopbox, S3, OneDrive등과 같은 곳에 파일을 업로드해 동기화할 수 있지만 동기화 속도가 느리고 무료버전은 용량에 제한이 있어서 포기
- Github을 연동하면 개발자 친화적이고, 동기화 속도도 빠르고, 용량도 무제한이고, 글만 작성해도 자동으로 커밋이 찍히기 때문에 잔디를 심어야 한다는 압박감을 해소할 수 있어서 채택!
옵시디언에 있는 글들이 클릭 한 번으로 개인 블로그, Github, 노션에 배포 및 수정이 되면 좋겠다.
- 개인 블로그, Github, 노션에 올릴 수 있는 커스텀 플러그인들은 많지만 아직 확인을 안 해봄.
- 업로된 글이 수정 가능한지도 잘 모르겠음

노션의 글을 옵시디언으로 옮기는 방법

옵시디언 실행 -> 새 보관소 생성 클릭 후 생성합니다.

우측하단 설정 아이콘 클릭 -> 커뮤니티 플러그인 선택 -> 커뮤니티 플러그인 탐색 버튼 클릭 -> importer 검색 후 설치 -> 설치 완료 되면 활성화 버튼 클릭 -> 활성화가 되면 좌측 사이드바에 표시된 것처럼 importer 아이콘이 생성됩니다.
노션 콘텐츠 내보내기, **주의할 점으로 내보내기 형식은 Html로 해야 됩니다.
추출된 zip 파일 importer에서 선택 후 import 버튼 클릭 합니다.
import가 성공하면 노션에 작성한 글들이 옮겨와 지고 단축키 cmd + G로 그래프 뷰 보기를 활성화하면 아래와 같이 비슷한 그래프를 볼 수 있습니다.

로컬에 있는 글들을 GtiHub repository에 백업하기 (mac os 기준)

github private repository 만들기
옵시디언에 서 git을 원활하게 사용해 줄 수 있게 만든 커스텀 플러그인 Obsidian Git가 있지만 해당 플러그인에 git-lfs가 없어어 인지 저처럼 큰 용량을 import해온 경우 Obsidian Git가 정상적으로 작동하지 않으므로 터미널을 사용해 git 작업을 하는 게 훨씬 속편 합니다. Obsidian Git은 추후 자동 백업을 편하게 해 주는데 도움이 되므로 작은 파일 단위로 보낼 때 사용하면 매우 편해요!
1. 터미널로 해당 옵시디언 폴더 이동
2. git init
3. git remote set-url origin "생성한 github repository url"
4. git add.
5. git commit -m “first commit”
6. git push origin main
정상적으로 git push가 완료되면 옵시디언에 있는 글들이 github에 업로드된 것을 확인할 수 있습니다.

Obsidian Git플러그인으로 자동 동기화 & 백업 환경 구축하기

우측하단 설정 아이콘 클릭 -> 커뮤니티 플러그인 선택 -> 커뮤니티 플러그인 탐색 버튼 클릭 -> Obsidian Git검색 후 설치 -> 설치 완료 되면 활성화 버튼 클릭
로컬에 있는 글들을 GtiHub repository에 백업하기 (mac os 기준)에서 이미 git 연동을 했기 때문에 별도의 git 환경설정은 하지 않습니다.
좌측 하단 환경 설정 아이콘 클릭 -> Obsidian Git 클릭 이동을 하면 Git Backup setting을 할 수 있습니다.
자동 백업 환경 설정을 해줍니다. 이미지 출처 (선택)
- ① 자동으로 commit과 push를 해주는 설정입니다. ON으로 바꿉시다.
- ②.③ commit과 push 주기입니다. 동일한 시간으로 맞추시면 됩니다. 5로 맞추면 5분마다 변경된 파일이 있으면 깃헙 저장소에 전송을 한다고 생각하시면 됩니다.
- ④ pull 주기입니다. 저는 1로 설정하였습니다. 1분마다 깃헙 저장소에서 내용들을 끌고 옵니다.
저는 git 환경이 익숙해서 위 예시처럼 특정 간격으로 백업하는 것보다 Obsidian Git: Create backup을 cmd+Shift+S 단축키로 등록해서 저장할 때마다 자동으로 git repository에 push 되도록 설정했습니다.

그 외 git을 다룰 줄 아는 개발자라면 설명문 봐도 어떻게 작동하는지 알 수 있으니 자세한 내용은 생략하겠습니다. 혹 자동 배포에 관해 궁금한 점이 있으면 댓글로 남겨주세요!

아이패드 & 아이폰 환경에서 옵시디언 연동하기

처음에는 옵시디언 앱을 설치하고 Obsidian Git으로 github에 올라간 옵시디언 저장소를 클론 해오면 간단하게 될 줄 알았습니다. 그런데… 위에서 말한 것처럼 Obsidian Git은 아직 대용량 파일을 전송하거나 전달받지 못하므로 노션에 있는 글들을 생각 없이 때려 박아 비대하게 커져 버린 저의 옵시디언 저장소를 당겨오지 못하는 상황이 발생했습니다. 그래서 Obsidian Git 공식문서를 찾아보니 Working Copy라는 앱을 이용해 IOS 환경에 git repository를 가져온 후 해당 폴더를 복붙 하라고 해서 그대로 진행했습니다.

-모바일 환경 연동 방법 작성중-