개념적 구조 정하는 것 > 논리적 모델링 데이터베이스 구축에 필요한 걸 정하는 것 > 물리적 모델링 // 제약사항, 데이터 타입 설정 등

데이터 모델

데이터를 사용하려는 목적에 맞게 정리하고 체계화해놓은 모형

개체Entity: 저장하고 싶은 데이터의 대상 Entity: 실제 대상 하나하나 row Entity Type: 일반화한 Entity 종류 table 속성Attribute: Entity에 대해서 저장하려는 내용 column 관계Relationship: Entity들 사이 연결점 제약 조건 Constraint: 여러 데이터 요소들에 있는 규칙

데이터 모델링은 Entity, Attribute, Relationship, Constraint를 파악하고, 발전시켜 데이터 모델을 만드는 과정 저장하고자 하는 데이터에서 Entity, Attribute, Relationship, Constraint 파악하여 데이터베이스를 구축할 때 기반이 될 모델 만들기

Relational Model: 데이터를 relation, 즉 테이블로 정리해서 표현한 모델 Relation은 테이블을 의미하는 수학적 표현 Relationship 테이블들 사이 맺어지는 관계

단점 row가 있어서 Entity, Attribute, Relationship, Constraint 등 구조 설계 불필요 Foregin Key를 확인해야하기 때문에 relationship의 특성을 한눈에 알기 힘듦.

Entity Relationship Model(ERM) Entity와 Relationship 중심으로 표현 Entity에 attribute를 넣고 Entity 선으로 연결

데이터 모델 스펙트럼

• 개념 모델Conceptual Model: 큼지막한 entity와 간단한 연결 관계, 대략적인 구조 파악 :: 경영인, 또는 기획자 사진 설명을 입력하세요.
• 논리 모델Logical Model: entity와 attribute, primary key foreign key 표시 :: 개발자 구체화 단계 사진 설명을 입력하세요.
• 물리 모델Physical Model: 변수이름, 데이터타입, 인덱스 등 구체적으로 표시 :: 데이터베이스 구축 단계

단점

데이터 중복 저장, NULL이 많음 연산 실행이 너무 오래 걸림 원하는 정보를 찾을 수 없음 틀린 데이터를 저장하고 있음

장점

중복, 틀린 데이터 없음 빠르고 정확하게 데이터를 다룰 수 있음 중복되는 데이터가 저장되지 않는다 NULL이 생기지 않는다 데이터가 늘어날 때 테이블 구조가 변하지 않는

데이터 모델링을 어떻게 했는지에 따라, 데이터베이스가 좋을 수도 나쁠 수도 있음

ERD

엔터티-관계 다이어그램(Entity-Relationship Diagram) 데이터 모델링의 일종 각 엔터티는 시스템 내의 구체적인 데이터 항목을 나타내며, 관계는 이러한 엔터티 간의 연결을 보여줌

데이터 모델링은 ERD를 만들고 관계형 데이터베이스 설계를 포함하는 과정 전반을 의미

SSR 환경(Node.js) 메모리 누수 디버깅 가이드 메모리 누수는 실제로는 필요하지 않은데, 메모리를 계속 차지하고 있는 현상

JS를 동작시킬 메모리가 부족하니까, 성능이 좋지 않게 됨 -GC의 활동이 늘어나면, CPU 사용량이 늘어나요. -CPU intensive한 작업이 늘어나면, 이벤트 루프가 블로킹되서 연산이 느려져요 띄워놓은 Node.js 서버가 죽어요 -SIGABRT 등의 시그널로 인한 프로세스 종료 -인스턴스가 재시작되고 일부 요청에 대한 응답이 실패 -로드밸런서가 HTTP Status 502(Bad Gateway) 에러를 뱉을 수 있어요. -가용성에 문제가 있을 수 있단 뜻이에요.

힙메모리를 늘려주거나, 메모리 누수의 범인을 디버깅한다

메모리 누수가 있는지 어떻게 알 수 있어요? Allocation failed-JavaScript heap out of memory

Server Side Grafana, DATADOG, AWS Cloudwatch

힙메모리를 늘려줘도, 이 코드는 계속 메모리 누수를 일으켜요.

V8의 메모리 관리 방식

살아남은 객체들은 계속해서 힙메모리에 존재해요! 가비지 콜렉터로부터 계속 살아남으면 어떻게 될까요?

Node.js 메모리 부족 어떻게 해결함? –max-old-space-size

계속 살아남은 객체는 Old space로, 계속 힙메모리를 차지하면 OOM

힙메모리를 늘리는 것이 무조건적인 정답은 아님

대표적인 메모리 누수를 일으키는 요인들 -전역변수 -해제되지 않은 타이머 -클로저

Node –inspect index.js

개발자 도구 – 메모리

Shallow Size: 오브젝트 자신의 크기bytes Retained Size: 나 자신 + 참조하고 있는 오브젝트들의 크기

Shallow Size에 비해서 Retained Size가 큰 것들을 찾기

Using 현재 JavaScript TC39 Stage 3 C#의 using Let, const, var 같이 변수를 선언할 때 쓰는 키워드 스코프 끝에서 Symbol.dispose()를 호출해서 클린업 할 수 있음

서버 환경과 클라이언트 환경으로 나눠서 디버깅하자 서버 환경에서는 node –inspect 옵션을 쓰자 timeline으로 힙메모리 사용량을 프로파일링하는 것이 유용하다 Shallow Size 대비 Retained Size가 큰 객체를 찾자 Using을 잘 쓰면 덜 고통스러울지도!

어떤 클래스가 단 하나의 인스턴스만을 가지도록 보장하며, 이 인스턴스에 접근할 수 있는 전역적인 접근점을 제공하는 디자인 패턴 어떤 클래스에 대해 하나의 인스턴스만 필요할 때 유용

Private Constructor

클래스의 생성자를 private으로 만들어 외부에서 직접 객체를 생성하는 것을 막음

Static Instance

클래스 내부에서 유일한 인스턴스를 생성하고, 이에 접근할 수 있는 정적 메서드나 속성을 제공

Lazy Initialization(지연 초기화)

인스턴스가 필요한 시점에 생성

헤드퍼스트 디자인 패턴

스레드 풀, 캐시, 대화상자, 사용자 설정, 레지스트리 설정을 처리하는 객체, 로그 기록용 객체, 디바이스 드라이버 등 객체를 사용할 때 인스턴스가 2개 이상이면 오류가 나는 경우, 싱글톤 패턴을 통해 인스턴스를 하나만 생성

전역 변수를 사용할 때와 마찬가지로 객체 인스턴스를 어디서든지 엑세스할 수 있게 만들 수 있으며, 전역 변수를 쓸 때처럼 여러 단점을 감수할 필요도 없음

자바스크립트의 싱글톤 패턴

class Singleton {
  constructor() {
    ...
  }

  static instance = null;

  static getInstance() {
    if (!Singleton.instance) {
      Singleton.instance = new Singleton();
    }
    return Singleton.instance;
  }

}

const singleton1 = Singleton.getInstance();
const singleton2 = Singleton.getInstance();

console.log(singleton1 === singleton2); // true

객체 생성을 캡슐화하고, 생성되는 구체적인 객체의 유형을 클라이언트 코드로부터 분리하는 데 사용됨

객체 생성을 담당하는 팩토리 클래스를 도입. 클라이언트 코드는 팩토리 클래스를 통해 객체를 생성하며, 이를 통해 클라이언트 코드는 구체적인 객체의 클래스에 대한 지식 없이도 해당 객체를 얻을 수 있음

Product Interface

생성될 객체에 대한 인터페이스를 정의

Concrete Product Classes

제품 인터페이스를 구현한 실제 객체들

Factory Interface

객체를 생성하는 메서드를 선언한 인터페이스

Concrete Product Classes

팩토리 인터페이스를 구현하여 객체를 생성하는 구체적인 클래스들

Client

팩토리 클래스를 통해 객체를 생성하는 주체로, 구체적인 객체의 클래스에 대한 지식 없이도 객체를 생성 가능자

자바스크립트 코드로 알아보기

// 제품 인터페이스
class Product {
  display() {
    throw new Error("Method 'display' must be implemented");
  }
}

// 구체적인 제품 클래스
class ConcreteProductA extends Product {
  display() {
    console.log("Product A");
  }
}

class ConcreteProductB extends Product {
  display() {
    console.log("Product B");
  }
}

// 팩토리 인터페이스
class Factory {
  createProduct() {
    throw new Error("Method 'createProduct' must be implemented");
  }
}

// 구체적인 팩토리 클래스
class ConcreteFactoryA extends Factory {
  createProduct() {
    return new ConcreteProductA();
  }
}

class ConcreteFactoryB extends Factory {
  createProduct() {
    return new ConcreteProductB();
  }
}

// 클라이언트
const factoryA = new ConcreteFactoryA();
const productA = factoryA.createProduct();
productA.display(); // 출력: Product A

const factoryB = new ConcreteFactoryB();
const productB = factoryB.createProduct();
productB.display(); // 출력: Product B

객체에 동적으로 새로운 책임을 추가하는 패턴 상속을 통해 기능을 확장하는 대신, 객체를 감싸는 방식으로 기능을 추가하거나 변경 기능을 조합하여 새로운 객체를 생성 가능

서브클래스를 만드는 방식으로 행동을 상속받으면, 그 행동은 컴파일할 때 완전히 결정됨. 게다가 모든 서브클래스에서 똑같은 행동을 상속받아야함 => 구성을 통해 객체의 행동을 확장하면 실행 중에 동적으로 행동을 설정가능함

Component 구성 요소

인터페이스나 추상 클래스로 정의된 기본 객체 객체에 동적으로 책임을 추가할 수 있어야 함

ConcreteComponent 구체적인 구성 요소

Component를 구현한 구체적인 클래스 기본 기능을 제공

Decorator 데코레이터

Component와 동일한 인터페이스를 가지면서 내부에 Component를 갖는 클래스 자신의 행위를 수행한 후에 또 다른 Component를 호출하여 작업을 전달

ConcreteDecorator 구체적인 데코레이터

Decorator를 구현한 구체적인 클래스 추가적인 기능을 제공하거나 기존 기능을 수정함

확장성

새로운 기능을 추가하거나 변경하기 쉬움. 상속보다 유연하게 기능을 확장 가능

구성을 통한 재사용

객체를 감싸는 방식을 통해 기능을 조합하여 재사용 가능

자바스크립트에서 이해하기

Component

class Coffee {
  cost() {
    return 5; // 기본 가격
  }

  description() {
    return '기본 커피';
  }
}

Decorator

class CoffeeDecorator {
  constructor(coffee) {
    this._coffee = coffee;
  }

  cost() {
    return this._coffee.cost();
  }

  description() {
    return this._coffee.description();
  }
}

ConcreteComponent

class MilkDecorator extends CoffeeDecorator {
  constructor(coffee) {
    super(coffee);
  }

  cost() {
    return super.cost() + 2; // 우유 추가 가격
  }

  description() {
    return super.description() + ', 우유 추가';
  }
}

class SugarDecorator extends CoffeeDecorator {
  constructor(coffee) {
    super(coffee);
  }

  cost() {
    return super.cost() + 1; // 설탕 추가 가격
  }

  description() {
    return super.description() + ', 설탕 추가';
  }
}

실행

// 기본 커피 주문
let simpleCoffee = new Coffee();
console.log(simpleCoffee.description()); // 기본 커피
console.log(simpleCoffee.cost()); // 5

// 우유 추가한 커피 주문
let milkCoffee = new MilkDecorator(simpleCoffee);
console.log(milkCoffee.description()); // 기본 커피, 우유 추가
console.log(milkCoffee.cost()); // 7

// 설탕 추가한 커피 주문
let sugarCoffee = new SugarDecorator(simpleCoffee);
console.log(sugarCoffee.description()); // 기본 커피, 설탕 추가
console.log(sugarCoffee.cost()); // 6

// 우유와 설탕 모두 추가한 커피 주문
let milkAndSugarCoffee = new SugarDecorator(new MilkDecorator(simpleCoffee));
console.log(milkAndSugarCoffee.description()); // 기본 커피, 우유 추가, 설탕 추가
console.log(milkAndSugarCoffee.cost()); // 8

OCP(Open-Closed Principle)

클래스는 확장에는 열려 있어야 하지만 변경에는 닫혀있어야한다는 디자인 원칙

옵저번 패턴은 객체 간의 일대다 의존 관계를 정의하는 패턴 어떤 객체의 상태가 변할 때, 그 객체에 의존하는 다른 객체들이 이 변화를 통지받아 자동으로 업데이트될 수 있도록 하는 구조 객체 간의 결합도를 낮추고, 확장성을 높이는데 도움을 줌

장점

비동기적인 이벤트 처리에 유용하며, 객체 간의 강한 결합을 피하고, 이벤트가 발생할 때마다 관련된 옵저버들이 동작할 수 있도록 해줌 새로운 옵저버를 추가하거나 기존의 옵저버를 제거하는 것이 간단해 코드의 유지보수성과 확장성을 높이는데 도움 주체와 옵저버가 각각 독립된 객체로 존재하기 때문에 코드의 재사용성과 모듈화가 강화됨 이벤트 기반의 자바스크립트에 적합

단점

옵저버가 등록된 순서대로 이벤트를 받기 때문에, 순서가 중요하지 않은 경우 번거로울 수 있음 주체에서 옵저버를 명시적으로 제거하지 않을 경우 메모리 누수가 일어날 수 있음 이벤트가 발생할 때마다 모든 옵저버에게 통지되므로, 성능에 영향을 줄 수 있음 규모가 커지면서 관리해야할 옵저버의 수가 많아질 경우 코드가 복잡해질 수 있음

Subject

상태를 관리하는 주체 객체 옵저버들을 등록하고, 상태가 변할 때 등록된 옵저버들에게 알림을 보냄

Observer

주체의 상태 변화를 감시하고, 변화가 있을 경우 특정 동작을 수행하는 객체 주체에 등록되어 있어야 하며, 주체로부터 상태 변화에 대한 통지를 받게 됨

class Observable {
  constructor() {
    this.observers = [];  // 이벤트가 일어날때 알릴 observers list
  }

  subscribe(func) {  // observers list에 observer를 추가하는 메서드
    this.observers.push(func);
  }

  unsubscribe(func) {  // observers list에서 observer를 제거하는 메서드
    this.observers = this.observers.filter((observer) => observer !== func);
  }

  notify(data) {  // 이벤트가 일어날 때 모든 observers에게 알리는 메서드
    this.observers.forEach((observer) => observer(data));
  }
}

export default function App() {
  return (
    <div className="App">
      <Button>Click me!</Button>
      <FormControlLabel control={<Switch />} />
    </div>
  );
}

import { ToastContainer, toast } from "react-toastify";

function logger(data) {
  console.log(`${Date.now()} ${data}`);
}

function toastify(data) {
  toast(data);
}

export default function App() {
  return (
    <div className="App">
      <Button>Click me!</Button>
      <FormControlLabel control={<Switch />} />
      <ToastContainer />
    </div>
  );
}

import { ToastContainer, toast } from "react-toastify";

function logger(data) {
  console.log(`${Date.now()} ${data}`);
}

function toastify(data) {
  toast(data);
}

observable.subscribe(logger);
observable.subscribe(toastify);

export default function App() {
  function handleClick() {
    observable.notify("User clicked button!");
  }

  function handleToggle() {
    observable.notify("User toggled switch!");
  }

  return (
    <div className="App">
      <Button>Click me!</Button>
      <FormControlLabel control={<Switch />} />
      <ToastContainer />
    </div>
  );
}

헤드 퍼스트 디자인 패턴

느슨한 결합의 위력

• subject는 옵저버가 특정 인터페이스를 구현한다는 사실만 압니다.
• 옵저버는 언제든지 새로 추가할 수 있습니다.
• 새로운 형식의 옵저버를 추가할 때도 주제를 변경할 필요가 전혀 없습니다
• 주제와 옵저버는 서로 독립적으로 재사용할 수 있습니다. 주제나 옵저버가 달라져도 서로에게 영향을 미치지 않습니다.

리액트 hook의 등장 배경

1. 상태 관리나 생명주기 메서드를 사용하기 위해서는 클래스 컴포넌트 안에 많은 코드를 작성해야 했기 때문에, 컴포넌트의 가독성이 떨어지고 유지보수하기 어려움

2. 클래스 컴포넌트에서는 this 키워드를 사용해야 하기 때문에, 코드 작성 시 바인딩 문제로 혼란스러움

클래스형 컴포넌트의 이러한 문제점으로 리액트 16.8 버전에서 hook이 추가됨

함수형 반응형 프로그래밍

순수 함수와 데이터 스트림을 사용하여 시간에 따른 시스템 동작을 설명하는 데 중점을 두는 프로그래밍 패러다임 사용자 입력과 같이 데이터가 생성되는 대로 처리하고 시스템 전체에 변경 사항을 자동으로 전파하는 반응형 프로그래밍을 강조 FRP에서는 일반적으로 시간이 지남에 따라 새로운 값을 방출하는 데이터 스트림인 옵저버와 이러한 데이터 스트림의 변경에 반응하는 옵저버로 작업

노마드 코더 실전형 리액트 Hooks

useState

useInput

const useInput = (initialValue, validator) => {
  const [value, setValue] = useState(initialValue);
  const onChange = e => {
    const { target: { value }
    } = e;
    let willUpdate = true;
    if (typeof validator === "function") {
      willUpdate = validator(value);
    }
    if (willUpdate) {
      setValue(value);
    }
  };

  return { value, onChange };
};

useTabs

const useTabs = (initialTab, allTabs) => {
  if (!allTabs || Array.isArray(allTabs)) {
    return;
  }
  const [currentIndex, setCurrentIndex = useState(initailTab);

return { 
  currentItem: allTabs[currentIndex], 
  changeItem: setCurrentIndex  
  };
};

useEffect

useTitle

const useTitle = initialTitle => {
  const [title, setTitle] = useState(initialTitle);
  const updateTitle = () => {
    const htmlTitle = document.querySelector('title');
    htmlTitle.innerText = title;
  };

  useEffect(updateTitle, [title]);
  return setTitle;
};

useClick

const useClick = (onClick) => {
  if (typeof onClick !== "function"){
    return;
  }
  const element = useRef();

  useEffect(() => {
    if (element.current) {
      element.current.addEventListener("click", onClick);
    }
    return () => {
      if (element.current) {
        element.current.removeEventListener("click", onClick);
      }
    };
  }, []);
  return element;
};

useConfirm & usePreventLeave

const useConfirm = (message, callback, rejected) => {
  if (typeof callback !== "function" || typeof rejected !== "function") {
    return;
  }
  const confirmAction = () => {
    if (confirm(message)) {
      callback();
    } else {
      rejected();
    }
  };
  return confirmAction;
};

const usePreventLeave = () => {
  const listner = (event) => {
    event.preventDefault();
    event.returnValue = "";
  };
  const enablePrevent = () => {
    console.log("enablePrevent");
    window.addEventListener("beforeunload", listner);
  };
  const disablePrevent = () =>
    window.removeEventListener("beforeunload", listner);
  return { enablePrevent, disablePrevent };
};

useBeforeLeave

const useBeforeLeave = (onBefore) => {
  const handle = (event) => {
    const { clientY } = event;
    console.log(clientY);
    if (clientY < 0) onBefore();
  };

  useEffect(() => {
    document.addEventListener("mouseleave", handle);
  }, []);
};

useFadeIn & useNetwork

const useFadeIn = (duration = 1, delay = 0) => {
  if (typeof duration !== "number" || typeof delay !== "number") {
    return;
  }
  const element = useRef();
  useEffect(() => {
    if (element.current) {
      const { current } = element;
      current.style.transition = `opacity ${duration}s ease-in-out ${delay}s`;
      current.style.opacity = 1;
    }
  }, []);
  return { ref: element, style: { opacity: 0 } };
};

const useNetwork = () => {
  const [status, setStatus] = useState(navigator.onLine);
  const handleChange = () => {
    console.log("handle chage");
    setStatus(navigator.onLine);
  };
  console.log("useNetwork", navigator.onLine);
  useEffect(() => {
    window.addEventListener("online", handleChange);
    console.log("online");
    return () => window.removeEventListener("online", handleChange);
  }, []);
  return status;
};

useScroll & useFullscreen

const useScroll = () => {
  const [state, setState] = useState({ x: 0, y: 0 });
  const onScroll = (event) => {
    setState({ y: window.scrollY, x: window.scrollX });
  };
  useEffect(() => {
    window.addEventListener("scroll", onScroll);
    return () => {
      window.removeEventListener("scroll", onScroll);
    };
  }, []);
  return state;
};

const useFullScreen = () => {
  const element = useRef();
  const triggerFul = () => {
    if (element.current) {
      console.log(element);
      element.current.webkitRequestFullscreen();
    }
  };
  return { element, triggerFul };
};

useNotification

const useNotification = (title, options) => {
  if (!("Notification" in window)) {
    return;
  }
  const fireNoti = () => {
    if (Notification.permission !== "granted") {
      Notification.requestPermission().then((permission) => {
        if (permission === "granted") {
          new Notification(title, options);
        } else {
          return;
        }
      });
    } else {
      console.log("aaa");
      new Notification(title, options);
    }
  };
  return fireNoti;
};

useAxios

const useAxios = (opts, axiosInsntance = defaultAxios) => {
  const [state, setState] = useState({
    loading: true,
    error: null,
    data: null
  });
  const [trigger, setTrigger] = useState(0);
  if (!opts.url) {
    return;
  }
  const refetch = () => {
    setState({
      ...state,
      loading: true
    });
    setTrigger(Date.now());
    console.log("refetch", Date.now());
  };
  useEffect(
    () => async () => {
      await axiosInsntance(opts)
        .then((response) => {
          setState({
            loading: false,
            error: null,
            data: JSON.stringify(response)
          });
        })
        .catch((error) => {
          setState({
            ...state,
            error: error
          });
        });
    },
    [trigger]
  );
  return { ...state, refetch };
};
export default useAxios;

What is Memoization?

Memoization은 메모리 공간을 더 많이 사용하는 대가로 컴퓨터 프로그램의 속도를 올리는데 사용되는 최적화 기술이다.

이 속도는 같은 input parameter가 제공되었을 때 반복적인 계산을 피하고 대신에 캐시된 결과를 사용하기 때문이다. 동시에, 캐시된 결과를 위해 여분의 공간이 사용되기 때문에 높은 메모리 사용을 초래한다.

만약 다음과 같은 이슈를 다뤄야 한다면, memoizing을 해야한다:

1. 많은 계산을 하는 높은 함수는 효율적인 수행을 위해 결과를 캐시해야한다.
2. 큰 컴포넌트는 같은 input이 주어졌을때 같은 결과를 렌더링하고 이를 Pure Component라고 부른다. 이 경우, 부모가 리렌더링되지만 Pure Component의 props는 변하지 않을때, 불필요한 비싼 렌더가 memoized되어 스킵될 수 있다.
3. Pure component의 props나 dependencies to a dependency array가 전달될 때객체나 함수의 참조 무결성을 유지한다.

How Does Memoization Work?

몇몇 memoization 기술의 경우, React는 컴포넌트가 리렌더링될 것인지를 결정하기 위해 컴포넌트의 props의 얕은 동등 비교를 수행한다. 예를 들어, React.Memo & React.PureComponent가 있다.

만약 얕은 비교 이상을 수행하려면, React.momo는 두 번째 인자로 사용자가 정의한 동등 비교 함수를 가지며 PureComponent의 경우 shouldComponentUpdate 라이프사이클 메서드를 재정의한다.

다른 한편으로, useMemo()와 useCallback은 캐시된 값이 유효한지판단하기 위해 dependency array에 의존한다.

만약 dependency array가 비어있다면, 캐시 무효화가 발생하지 않을 것이다.

Drawbacks of Permature Memoization

너무 멀리가기 전에, premature optimization에 관해 경고하고 싶다.

당신은 애플리케이션에서 프로그램의 병목현상으로 나타나는 일부만 memoize해야한다. 필요하지 않은 코드를 memoization하면 더 좋아지는 대신 더 나빠질 수 있다.

예를 들어:

1. memoization의 CPU/memory 비용은, 전에 언급한 것처럼, 더 많은 메모리 공간을 소비하면서 결과를 캐시함으로써 작동한다. 게다가, memoizationd은 캐시된 결과를 리턴할지 하지 않을지 결정하기 위해 props와 dependencies 비교를 필요로 하며 이는 추가적인처리가 필요하다,
2. React에서 Memoization은 더 많은 dependencies를 관리하기 위해 기존 코드에 추가 복잡성을 더한다. 모든 추가 복잡성은 고려해야할 overhead이다.
3. memoization의 결과로 캐시된 값들이 예상하지 못한 상황에서 다시 계산되지 않는다는 가정을 해서는 안된다.React는 필요한 경우에 캐시된 값들을 무효화할 수 있다. 따라서 bug를 피하기 위해서는 성능최적화를 위해서만 memoization을 사용해야한다.

useMemo에 관한 React 문서에 따르면:

"React에서 memoization을 의미적인 보장으로 사용하는 것이 아니라 성능 최적화로만 의존해야 한다."

또한 React.memo 문서에서 비슷한 문장을 찾을 수 있다:

"이 method는 성능최적화를 위해서만 존재한다. 렌더링을 "막기" 위해 의존하지 말아야 한다. 이는 버그를 일으킬 수 있다."

원칙적으로, 필요할 때만 최적화해라. 그것은 무슨 의미인가?

When to Memoize in React

memoize하지 말아야하는 경우를 알았으니, 사용할 경우와 어떻게 도움이 되는지에 대해 이야기해보겠다.

우선, 컴포넌트를 실행함으로써 시작하고 어떤 성능 이슈가 없는지 확인한다. React Devtools는 성능 이슈를 파악하는데 도움을 주는 유용한 도구이다.

만약 어떤 성능 이슈를 마주친다면, 다음 섹션에서 언급되는 memoization 기술을 사용하여 문제있는 컴포넌트를 최적화할 지 고려할 수 있다.

최적화가 완료된 후에는, 전과 후의 결과를 비교하여 성능향상이 있었는지 확인한다.

만약 성능향상이 미미하다면, 버그와 추가적인 overhead를 피하기 위해 memoization의 변경사항을 버리는 것이 좋을 것이다.

How to Implement Memoization in React

React.memo

useMemo

useCallback

How to Memoize Class-based Components

React.PureComponent

Conclusion

React의 Memoization은 강력한 도구이지만, trade-off가 따른기 때문에 React의 모든 것을 초기 최적화하는 것은 피하는 것을 권장한다.

React는 성능이 우수한 프레임워크이자 이미 여러 최적화를 진행 중이다. 따라서 특별히 필요하지 않으면, 추가적인 최적화는 필요하지 않을 수 있다.

이제 React에서 memoization을 사용하는 여러가지법을 알아봤고, 그것을 사용할때와 피해야할 때를 이해했을 것이다.

원문 https://www.bitovi.com/blog/how-and-when-to-memoize-your-react-application

객체 지향 프로그래밍

객체 지향 프로그래밍이란?

초기 프로그래밍은 단순히 코드의 순서대로 실행되는 순차적 프로그래밍 방식이었습니다. 반복문이 존재했지만 한계가 있었고 실행 순서를 강제로 변경하는 등의 방법으로 코드의 흐름을 제어하기 힘들었습니다. 이후 일정하게 반복되는 코드를 함수로 만들어 사용하는 절차적 프로그래밍 패러다임이 등장했습니다. 하지만 전역 변수를 사용했기 때문에 프로그램이 커질수록 변수명 관리에 어려움을 겪었습니다. 비슷한 변수명을 묶어서 관리하면서 서로 연관있는 데이터들을 모아두기 시작했고, 이는 해당 변수에 접근할 수 있는 구조체를 만들어냈습니다. 이 구조체를 바탕으로 데이터를 중심으로 코딩을 하게 되면 프로그래밍이 커져도 일관성을 유지하기 편하며, 함수까지 더해지면서 class가 탄생하게 되었습니다. 즉, 데이터와 처리방법을 분리해서 개발하던 절차식 프로그래밍과 달리, 데이터가 처리방식을 하나의 모듈로서 관리를 하게 되면서 작은 프로그래밍들이 독립적으로 돌아가는 형태가 되었고, 이를 조립하고 결합하는 방식의 개발 방법론이 등장하게되었습니다. 이과정에서 구조체와 함수를 합쳐서 선언하는 것을 class라고 부르기로 했고, class 내의 값과 동작을 실체로 보며 object로 칭했습니다. 결국, 프로그램을 객체로 바라보는 관점으로 프로그래밍하는 객체지향 프로그래밍Object-Oriented Programming(OOP)방법이 지금까지도 유용한 방법론으로 소개되고 있습니다.

캡슐화

객체를 독립적으로 분리하면서, 객체의 모든 데이터에 접근할 필요성이 사라졌고, 내부의 데이터는 내부에서 알아서 조작할 수 있도록 하고 외부에서는 필요한 내용만 만들어 두는 편이 안정성과 사용성 측면에서 효율적이었습니다. 따라서 외부로 노출해야 하는 값과 내부에서만 사용하는 값을 구분하는 기능을 추가하였습니다. 이것을 데이터를 보호해주는 캡슐을 통해 내부 데이터에 바로 접근하지 못하게 하고 필요한 메소드만 열어두는 캡슐화라고 부릅니다.

# 프리픽스

class Human {
  #age = 10;

  getAge() {  // getter
    return this.#age; 
  }
}

const person = new Human();

console.log(person.#age); // Error TS18013: Property '#age' is not accessible outside class 'Human' because it has a private identifier.
console.log(person.getAge()); // 10

상속

재사용성을 위해 객체를 사용하는 과정에서, 여러 개의 변수와 여러 개의 함수가 섞여 있다보니 일부 로직은 같고, 일부는 달라져야하는 상황이 발생했습니다. 따라서 객체의 일부분만 재사용하는 방법이 필요해졌고, 상속을 통해 객체에서 공통된 부분만 따로 만들어서 그 코드를 같이 상속받아서 활용을 하고 나머지 달라지는 것들만 각자 코드를 작성하는 방식을 만들게 되었습니다.

추상화

상속을 통해 객체를 분리하고 연결하는 과정에서, 공통적인 부분을 모아서 상위의 개념으로 새롭게 이름붙이는 추상화가 필요해졌습니다. 예를들어, 강아지와 고양이 등의 클래스의 공통부분을 동물이라는 클래스로 만들어 상속할 수 있습니다.

다형성

let zergling1 = new Zergling()
let zergling2 = new Zergling()
let hydralisk1 = new Hydralisk()
let hydralisk2 = new Hydralisk()
let mutalisk = new Mutalisk()
let overload = new Overload()

let units = [zergling1, zergling2, hydralisk1, hydralisk2, mutalisk, overload]

// 모두 같은 이름의 moveTo 메소드를 호출하지만 각자의 방식대로 동작한다.
units.forEach(unit => unit.moveTo(300, 400))

상속과 추상화를 사용해서 추상화된 유닛이라는 타입이 하위 타입인 여러가지 타입으로 참조할 수 있는 다형성을 활용할 수도 있습니다. 예를들어, 같은 Unit의 moveTo 메소드를 사요하지만, 각자 정의된 방식이 있기 때문에 각자의 방식대로 동작하며 다형성을 통해 객체의 일부분만 재사용할 수 있습니다.

정리

객체지향 프로그래밍은 프로그램이 커지면서 생기는 문제점을 해결하기 위해 나온 하나의 관점이자 방법론입니다. 기존의 방식에서 변수를 하나씩 관리하다 보니 변수명 관리에 어려움이 있었고, 이러한 문제를 해결하기 위해 구조체라는 타입을 만들어 데이터를 중심으로 관리를 하였습니다. 또한 추가로 데이터와 함수를 한데 묶어서 관리하는 관점이 생겨났고, 하나의 큰 프로그래밍을 작은 문제를 해결하는 독립적인 단위로 만들 수 있었습니다. 이렇게 작은 단위로 관리를 하게 되니 개발과 유지보수가 간편하게 된다는 장점이 있었으며 현재 널리 사용되고 있는 방법론입니다.

자바스크립트의 클래스

사실 자바스크립트의 탄생 시점에서는 객체지향 프로그래밍의 필요성이 널리 알려지지 않은 상태였기 때문에, 자바스크립트에 클래스는 없었고, 생성자 함수를 통해 클래스를 흉내내는 방식이었습니다. 그러다 ES6에 들어 클래스가 추가되었습니다.

프로그래밍의 독립적인 단위인 객체를 설계하고 찍어낼 수 있는 틀과 같은 구조를 클래스라고 하고, 클래스에 만들어진 인스턴스를 객체라고 하여 프로그래밍의 모든 것들을 객체로 간주하여 객체간의 상호작용을 중심으로 생각하고 설계하는 프로그래밍 개념이 바로 Object-Oriented Programming입니다.

constructor와 메서드

constructor

생성자는 클래스로부터 객체를 생성할 때 호출되는 특별한 메서드입니다. 클래스 내부에서 constructor 키워드를 사용하여 정의하며, 객체의 초기 상태를 설정하거나 인스턴스 변수를 초기화하는 등의 작업을 수행하기 때문에 클래스 내에 단 하나만 존재할 수 있습니다.

메서드

메서드는 클래스에 속한 함수로, 객체가 수행할 수 있는 동작이나 기능을 정의합니다. 클래스 내에 일반적인 함수처럼 정의되며 인스턴스가 생성될 때마다 메서드는 해당 인스턴스에 대해 별도로 생성되지 않고 클래스의 프로토타입에 할당됩니다.

클래스의 인스턴스 생성 과정

class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  greet() {
    console.log(`Hello, my name is ${this.name} and I am ${this.age} years old.`);
  }
}

// 객체 생성
const person1 = new Person('John', 30);

// 메서드 호출
person1.greet(); // Hello, my name is John and I am 30 years old.

1. 런타임이 실행되기 전에, 자바스크립트 엔진의 평가과정에서 Person 클래스 선언이 호이스팅되지만 초기화되지 않은 상태로 TDZ에 들어간다.
2. Person 생성자 함수가 호출되면서 빈객체가 생성된다.
3. 생성자 함수의 constructor가 호출되면서 빈객체에 해당 인스턴스의 name 프로퍼티에 인수로 전달받은 name을 추가된다.
4. 해당 인스턴스의 age 프로퍼티에 인수로 전달받은 age가 추가된다.
5. person1의 greet이 호출되면, 스코프 체인에서 person1 식별자를 검색한 후 프로토타입 체인에서 greet 메서드를 검색하며 person1의 프로토타입인 Person.prototype에서 상속받은 greet 메서드를 호출한다.

카드 뒤집기 게임 살펴보기

대부분의 분들이 카드 클래스를 만들어 카드 인스턴스를 생성하고 모듈화하는 것을 첫 접근으로 잘 시작해주는 것을 확인할 수 있었습니다. 여기에 객체지향 프로그래밍 관점을 좀 더 추가해보겠습니다.

단, 당연히 설계자의 의도에 따라 코드는 달라지기 때문에, 정답 코드가 아님을 명시합니다.

단일 책임 원칙

객체지향프로그래밍의 관점에서 보면, 각각의 클래스는 독립되지만 서로 연결되어 하나의 프로그래밍을 구성하게 됩니다. 즉, 카드 요소를 생성해서 이벤트핸들러를 추가하는 작업은 물론, 카드 인스턴스를 배열에 보관하고, 이 게임을 관리하는 것까지 객체로 만들어서 서로 상호작용하여 객체지향적인 프로그래밍으로 만들 수 있을 것입니다.

이때, 각각의 클래스를 어떻게 분리하여 어떤 클래스가 어떤 데이터를 갖고 있고 어떤 동작을 수행할지에 대한 고민을 시작해야합니다. 즉 각각의 클래스에 하나의 책임을 부여하면 클래스 간의 의존성을 줄이고 독립적으로 변경 및 확장하며 유지보수가 쉬워집니다. 이것을 단일책임원칙이라고 부릅니다.

게임을 관리하는 클래스

1단계에서는 게임을 시작하는 기능만 추가되겠지만 추후 확장을 고려하여 게임을 관리하는 클래스를 만들어 게임의 흐름을 제어하는 등의 게임의 주요 로직을 담당하는 클래스입니다.

카드를 보관하는 클래스

전체 카드를 생성하고 관리하며, 카드를 섞는 등의 카드 관련 작업을 수행할 수 있으며, 게임을 관리하는 클래스에서 게임을 시작했을 때 카드를 섞는 메서드가 동작하도록 연결시킬 수 있습니다. 즉, 이 클래스는 전체 카드를 관리하는 작업에만 집중하고 게임의 진행과는 독립적으로 진행되어야합니다.

카드 클래스

개별 카드의 속성을 나타내고, 카드의 상태를 추적하는 등 개별 카드에 특화된 작업을 수행하는 클래스입니다. 카드의 스타일 속성을 지정하거나, 이벤트 핸들러를 추가하는 등의 작업을 수행할 수 있습니다.

상속과 추상화

또한 추상화와 상속을 사용하여 카드 클래스를 더 구체화할 수 있습니다. WinningCard와 LossingCard로 분리하고, 추상화된 Card 클래스를 만들어 공통된 카드 속성을 추가한 후 WinningCard와 LossingCard에 서로 다른 역할을 하는 메서드를 오버라이딩할 수 있습니다.

class AbstractCard {
  constructor(isWinningCard) {
    this.node = this.createCardElement();
    this.isWinningCard = isWinningCard;
    this.handleCardClick();
  }

  createCardElement() {
    const button = document.createElement("button");
    button.style.height = "200px";
    button.style.width = "100px";
    button.innerText = "두근두근";
    return button;
  }

  handleCardClick() {
    this.node.addEventListener("click", () => {
      this.selectCard();
    });
  }

  // 추상 메서드로 하위 클래스에서 구현하여 오버라이딩되도록 함
  selectCard() {
    throw new Error('Abstract method. Subclasses should implement this.');
  }
}

class WinningCard extends AbstractCard {
  selectCard() {
    const contents = document.querySelector("#contents");
    contents.innerText = "당첨입니다 :D";
  }
}

class LosingCard extends AbstractCard {
  selectCard() {
    const contents = document.querySelector("#contents");
    contents.innerText = "꽝입니다!";
  }
}

의존성 주입

카드를 보관하는 클래스 내에서 카드 인스턴스를 생성하여 카드 인스턴스들을 관리하는 방식은 클래스 간의 의존성이 높아 결합도가 높습니다. 카드를 보관하는 클래스가 카드 클래스에 의존하고 있다고 표현하는데, 이를 외부에서 주입받도록 구현하여 클래스 간의 결합도를 낮추고, 코드의 유연성과 재사용성을 높일 수 있습니다.

class GameManager {
  constructor(cardsManager) {
    this.cardsManager = cardsManager;
  }

  startGame() {
    this.cardsManager.shuffleCards();
    // 게임 시작 로직 
  }
}

class CardsManager {
  constructor() {
    this.cards = [];
    this.createCards();
  }

  createCards() {
    // 전체 카드 생성 및 초기화...
  }

  shuffleCards() {
    // 카드 섞기 로직...
  }

  // 다른 카드 관련 메서드들...
}

class Card {
  // 카드의 속성과 메서드...
}

const cardsManager = new CardsManager();
const gameManager = new GameManager(cardsManager);

gameManager.startGame();

아토믹 디자인 패턴

소스코드를 아주 작은 컴포넌트 단위로 쪼개는 방법 컴포넌트 중복을 최소화하기 위해서 사용됨

Atom

가장 작은 단위의 컴포넌트 디자인과 기능의 최소 단위 원자는 어떠한 context가 주어지든지 이에 해당하는 컴포넌트가 생성될 수 있어야 한다. 따라서, 다양한 state를 가지고 있어야하며 추상적이지만 최대한 포용할 수 있게 설계 되어야 한다. 상태, 색상, 폰트, 애니메이션과 같은 추상적인 요소 포함 Button, Lavel, Text, CheckBox, Icon 등

Molecule

2개 이상의 원자를 엮어 조금 복잡한 단위의 분자가 생성됨 하나의 단위로 함께 동작하는 UI 컴포넌트들의 단순한 그룹 분자는 분자만의 프로퍼티를 가지고 있을 수 있고 이를 활용해 원자에 기능을 만들어 줄 수 있음 분자가 원자의 위치값을 지정하기도 함 InputForm, Navigation, Card 등

Oraganisms

원자와 분자를 조합하여 사용하는 컴포넌트 인터페이스가 어떻게 보이는지 시작하는 단계 유기체는 분자를 엮어 만들어서 생성되고 때로는 분자가 되지 않은 원자가 엮이기도 한다 유기체가 완성되면 컴포넌트가 최종 모습을 가지게 된다 하지만 여전히 contents에 따라 최대한 재사용성 높게 개발하는 것이 중요하다. 유기체는 분자와 원자의 위치값을 조정한다 예를 들어, InputForm을 Header 내에 포함하거나 Card 여러 개를 그리드 형태로 관리하는 것

Template

여러 유기체가 모여있는 단위 템플릿은 만들어진 유기체와 컴포넌트의 positions, placements를 정해주는 역할 단, 템플릿에서는 Styling이나 Color는 들어가지 않는다 템플릿의 역할은 페이지의 그리드를 정해주는 역할뿐임

Page

템플릿을 이용해서 각 그리드에 컴포넌트를 그려서 디스플레이

적용해보기

Atom

import React from 'react';
import Image from 'next/image';
import KakaoLogo from '../../../assets/kakao_login.png';

interface KaKaoLoginButtonProps {
  onClick: React.MouseEventHandler<HTMLDivElement>;
}

const KaKaoLoginButton: React.FC<KaKaoLoginButtonProps> = ({ onClick }) => {
  return (
    <div onClick={onClick}>
      <Image src={KakaoLogo} alt="카카오로그인" width={200} height={40} />
    </div>
  );
};

export default KaKaoLoginButton;

Organism

import React, { useEffect } from 'react';
import KaKaoLoginButton from '../../atoms/SocialLoginButton/KaKaoLoginButton';

const kakaoOauthURL = `https://kauth.kakao.com/oauth/authorize?client_id=${process.env.NEXT_PUBLIC_REACT_APP_KAKAO_API_KEY}&redirect_uri=${process.env.NEXT_PUBLIC_KAKAO_REDIRECT_URI}&response_type=code`;

const SocialLogin: React.FC = () => {
  const requestKakao = (): void => {
    window.location.href = kakaoOauthURL;
  };

  useEffect(() => {
    const urlParams = new URLSearchParams(window.location.search);
    const code = urlParams.get('code');

    if (code !== null && code !== undefined) {
      console.log('받아온 코드:', code);
    }
  }, []);

  return <KaKaoLoginButton onClick={requestKakao} />;
};

export default SocialLogin;

나눠보기

여전한 보노보노 색상 감각이지만 대충 이런 느낌인거같다..!

구조보기

src/
|-- components/
|   |-- atoms/
|   |   |-- AtomComponent1/
|   |   |   |-- index.js
|   |   |   |-- AtomComponent1.js
|   |   |   |-- AtomComponent1.css
|   |   |-- AtomComponent2/
|   |   |   |-- index.js
|   |   |   |-- AtomComponent2.js
|   |   |   |-- AtomComponent2.css
|   |-- molecules/
|   |   |-- MoleculeComponent1/
|   |   |   |-- index.js
|   |   |   |-- MoleculeComponent1.js
|   |   |   |-- MoleculeComponent1.css
|   |   |-- MoleculeComponent2/
|   |   |   |-- index.js
|   |   |   |-- MoleculeComponent2.js
|   |   |   |-- MoleculeComponent2.css
|   |-- organisms/
|   |   |-- OrganismComponent1/
|   |   |   |-- index.js
|   |   |   |-- OrganismComponent1.js
|   |   |   |-- OrganismComponent1.css
|   |   |-- OrganismComponent2/
|   |   |   |-- index.js
|   |   |   |-- OrganismComponent2.js
|   |   |   |-- OrganismComponent2.css

테스트의 종류

유닛 테스트Unit Test

코드의 개별 컴포넌트나 함수를 테스트하는 것 주로 모듈, 함수 혹은 컴포넌트 단위로 진행하며, 해당 단위가 의도한대로 동작하는지 검증

통합테스트Integration Test

여러 개의 유닛이나 컴포넌트를 함께 테스트하여 이들 간의 상호작용과 통합이 올바르게 이뤄지는지 확인. 시스템 전체의 안정성을 보장하는 데 기여.

E2E 테스트(End-to-End Test)

사용자 시나리오를 흉내내어 전체 애플리케이션의 동작을 테스트 실제 사용자가 마주할 상황을 최대한 모방하여 테스트하므로, 애플리케이션의 품질과 사용자 경험을 평가하는데 유용

스냅샷 테스트

UI 컴포넌트의 렌더링 결과를 스냅샷으로 캡처하고, 변경 사항이 있는지 확인 UI 변경을 쉽게 감지하고 예상하지 못한 레이아웃 변화를 방지함

회귀 테스트Regression Test

새로운 코드 변경이나 기능 추가 후에 시스템이 여전히 예전에 작동하던 기능들을 망가뜨리지 않았는지 확인하는 테스트 변경 사항이나 새로운 기능 추가로 인해 발생할 수 있는 예기치 못한 부작용을 방지하기 위해 필요

성능 테스트Performance Test

시스템의 성능과 안정성을 확인하는데 중점 부하 테스트, 성능 테스트, 신뢰성 테스트 등 대량의 데이터나 동시 사용자가 많은 상황에서 시스템이 어떻게 동작하는지를 평가

안정성 테스트Security Test

시스템의 보안에 중점을 둔 테스트, 잠재적인 보안 취약점을 찾고 해결함으로써 시스템을 보호 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 크로스 사이트 요청 위조(CSRF) 등을 확인하는데 사용

사용성 테스트Usability Test

사용자가 제품을 쉽게 이해하고 조작할 수 있는지를 평가 인터페이스, 플로우, 접근성 등을 고려하여 사용자 경험을 향상시키는데 도움

A/B 테스트

두 가지 또는 그 이상의 변형을 사용하여 어떤 버전이 사용자에게 더 효과적인지를 비교하는 테스트 주로 마케팅 캠페인이나 사용자 경험 개선을 위해 사용됨

테스트 도구

Jest

Facebook에서 만든 JavaScript 테스트 프레임워크 주로 유닛 테스트에 사용 Snapshot 테스트, 비동기 코드 테스트, mock를 지원하여 간편하게 사용 가능

Cypress

E2E 테스트에 특화된 도구 실제 브라우저에서 애플리케이션을 실행하며 테스트 사용자 인터랙션을 테스트하고 디버깅하는 데 용이하며, 가독성 좋은 테스트 코드를 작성 가능

Storybook

UI 컴포넌트의 렌더링 결과를 보여줌

Testing Library

React,Angular, Vue 등 다양한 프레임워크에 대한 테스트 도구를 제공하는 생태계 사용자 중심의 테스트 방법론을 채택하여 실제 사용자의 관점에서 테스트를 수행

TDD, Test-Driven Development

개발자가 코드를 작성하기 전에 테스트를 먼저 작성하는 방법론 코드의 요구 사항을 명확히 이해하고, 안정성 있는 코드를 유지할 수 있음

1. 구현하려는 동작을 설명하는 테스트 코드 작성
2. 테스트 실행, 아직 코드를 작성하지 않았으므로 실패함
3. 테스트를 통과하기 위한 코드를 작성
4. 테스트 실행하여 코드를 확인
5. 테스트를 통과하면 코드를 리팩터링

• 테스트를 먼저 작성함으로써, 개발자는 구현하려는 동작에 대해 먼저 생각하게 되어 특정한 요구사항에 맞는 코드를 작성할 수 있음
• 코드의 유지보수성을 향상시키고, 시간이 지나도 프로젝트의 유지 관리가 쉬워짐
• 코드 수정 시 미처 생각지 못한 부분에 대한 문제점을 미리 파악 가능
• 애플리케이션엥 대한 신뢰성이 높아짐
• 테스트 코드는 동작 방식을 설명하니, 테스트 파일 자체를 문서로 활용 가능

그냥 사용만 해보기

cypress

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  screenshotOnRunFailure: false,
  video: false,
  blockHosts: ['cdn.jsdelivr.net'],
  e2e: {
    setupNodeEvents(on, config) {},
    specPattern: 'test/*.spec.js',
    supportFile: false,
  },
});

describe("카드 컴포넌트 테스트", () => {
  it("카드 컴포넌트가 렌더링된다.", () => {
    cy.visit("http://localhost:3000");

    cy.get(".card").should("be.visible");
  });

  it("게임이 다시 렌더링된다.", () => {
    cy.visit("http://localhost:3000");

    cy.contains("button", "카드입니다").click();

    cy.contains("button", "다시 하기").click();

    cy.get(".card").should("be.visible");
  });
});

jest

const { Card, Cards } = require("../src/index");

describe("Card", () => {
  test("카드 결과보기 테스트", () => {
    const resetGameMock = jest.fn();
    const card = new Card(true, 0, resetGameMock, null);

    card.selectCard();

    expect(resetGameMock).toHaveBeenCalledTimes(1);
  });
});

describe("Cards", () => {
  test("카드 생성하고 리셋하기 테스트", () => {
    const createCardsMock = jest.spyOn(Cards.prototype, "createCards");
    const renderCardsMock = jest.spyOn(Cards.prototype, "renderCards");

    const cards = new Cards(5);
    cards.resetGame();

    expect(createCardsMock).toHaveBeenCalledTimes(1);
    expect(renderCardsMock).toHaveBeenCalledTimes(1);
  });
});

jest는 jsdom 라이브러리를 따로 또 설치한다는 점에서 그냥 cypress가 e2e테스트 무난한듯,, 사실 아직 어디서 테스트를 해야하는지 감이 잘 안잡히다보니 그냥 이런 도구가 있군,,하고 지나가게 된다.

MVC(Model-View-Controller)

• Model: 데이터와 비즈니스 로직을 관리

• View: 사용자에게 표시되는 인터페이스를 담당

• Controller: 모델과 뷰 간의 상호 작용을 조정하고 사용자 입력을 처리 MVC는 각 구성 요소가 서로 독립적이어야 하며, 모델과 뷰 간에 직접적인 연결이 없어야함 사용자 입력에 대한 응답으로 컨트롤러가 동작하며, 모델이 엄데이트되면 뷰가 갱신됨 일반적으로 html, css를 View, 컨트롤러를 js, 백에서 받아온 데이터를 Model로 생각

  // 데이터와 비즈니스 로직을 담당하는 View
  class UserModel {
  constructor(name) {
    this.name = name;
  }
  
  updateName(newName) {
    this.name = newName;
  }
  }

  // 사용자에게 표시되는 인터페이스를 담당하는 View
  class UserView {
  render(user) {
    console.log(`사용자 이름: ${user.name}`);
  }
  }

  class UserController {
  constructor(model, view) {
    this.model = model;
    this.view = view;
  }
  
  handleNameChange(newName) {
    this.model.updateName(newName);
    this.view.render(this.model);
  }
  }

MVVM(Model-View-ViewModel)

• Model: 데이터와 비즈니스 로직을 관리
• View: 사용자에게 표시되는 인터페이스를 담당
• ViewModel: 뷰를 표현하기 위한 뷰의 상태와 행동을 캡슐화하고, 뷰와 모델간의 통신을 중계 데이터 바인딩을 사용하여 뷰모델과 뷰 간에 간단한 통신을 가능하게 함 뷰모델은 주로 사용자 인터페이스의 상태를 유지하고 뷰에서 모델로의 변환 작업을 처리

// 뷰를 표현하기 위한 상태와 행동을 캡슐화하는 View Model
class UserViewModel {
  constructor(model) {
    this.model = model;
  }

  get name() {
    return this.model.name;
  }

  set name(newName) {
    this.model.updateName(newName);
  }
}

MVP(Model-View-Presenter)

• Model: 데이터와 비즈니스 로직을 관리

• View: 사용자에게 표시되는 인터페이스를 담당

• Presenter: 뷰와 모델 간의 중간 매개체. 사용자 입력을 처리하고 모델에서 데이터를 가져와 뷰에 업데이트하는 역할 뷰와 모델 간의 직접적인 연결을 피하면서 프레젠터를 통해 중재하도록 설계. 사용자 입력에 대한 로직은 프레젠터에서 처리되고, 뷰는 단순히 사용자 인터페이스를 표시하는 역할만 수행

  // 뷰와 모델 간의 중간 매개체로 동작하며 사용자 입력을 처리하고 모델에서 데이터를 가져와 뷰에 업데이트하는 Presenter
  class UserPresenter {
  constructor(model, view) {
    this.model = model;
    this.view = view;
  }
  
  handleNameChange(newName) {
    this.model.updateName(newName);
    this.view.render(this.model.name);
  }
  }

Controller, View Model, Presenter

Controller

사용자 입력을 감지하고 모델과 뷰를 업데이트하는 역할 사용자 입력을 처리하고 모델과 뷰 간의 상호 작용을 조정하는 것이 주된 목적

• 사용자의 액션을 감지하고 이에 대한 응답을 결정
• 모델의 업데이트를 담당하고, 모델이 변경되었을 때 뷰를 업데이트
• 일반적으로 컨트롤러와 뷰는 직접적으로 통신

ViewModel

뷰에 필요한 데이터를 제공하고, 뷰와 모델 사이의 중간 매개체 역할 뷰를 표현하기 위한 상태와 행동을 캡슐화하여 뷰와 모델 간의 결합을 완화하는 것이 주된 목적

• View를 표현하기 위한 데이터를 제공
• 사용자 인터페이스의 상태와 동작을 캡슐화하고, 뷰에 바인딩되어있는 데이터를 조작
• 주로 양방향 데이터 바인딩을 통해 뷰와 자동으로 동기화

Presenter

사용자의 입력을 처리하고, 모델과 뷰 간의 중개자 역할 뷰와 모델 간의 결합을 느슨하게 유지하면서 사용자 입력을 처리하고 뷰를 업데이트하는 것이 주된 목적

• 사용자 입력을 처리하고, 이에 대한 응답으로 모델을 업데이트하며 뷰를 업데이트
• 뷰와 모델 간의 직접적인 의존성을 피하기 위해 중간 역할을 수행
• MVP 패턴에서는 일반적으로 뷰와 모델 사이의 인터페이스 역할

다시보기

MVC

1. 사용자의 action이 Controller로 들어온다.
2. Controller는 사용자의 action을 확인하고, Model을 업데이트
3. Controller는 Model을 나타내줄 View를 선택
4. View는 Model을 이용하여 화면을 나타냄

Controller가 Model을 업데이트하고 View를 선택하면 View가 Model을 나타냄 View와 Model 사이의 의존성이 높아 어플이케이션이 커질 수록 복잡하고 유지보수가 어려움

/src
  /components
    UserView.js
    UserController.js
  /models
    UserModel.js
  /views
    App.js

import React from 'react';
import UserModel from '../models/UserModel';
import UserView from '../components/UserView';

class UserController extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      user: new UserModel('Ahhyeon'),
    };
  }

  handleNameChange = (newName) => {
    this.state.user.updateName(newName);
    this.forceUpdate();
  }

  render() {
    return (
      <div>
        <UserView user={this.state.user} />
        <button onClick={() => this.handleNameChange('Ahyeon')}>Change Name</button>
      </div>
    );
  }
}

export default UserController;

MVVM

1. 사용자의 action이 View를 통해 들어옴
2. View에 action이 들어오면, 캡슐화하여 View Model에 Action을 전달
3. View Model은 Model에게 데이터를 요청
4. Model은 View Model에게 요청받은 데이터를 응답
5. View Model은 응답받은 데이터를 가공하여 저장
6. View는 View Model과 Data Binding하여 화면을 나타냄

View와 Model의 의존성이 없음 캡슐화와 양방향 바인딩을 통해 View와 View Model의 의존성이 없음 각각의 부분이 독립적이기 때문에 모듈화하여 개발 가능

/src
  /components
    UserView.js
    UserViewModel.js
  /models
    UserModel.js
  /views
    App.js

// View
import React from 'react';

class UserView extends React.Component {
  render() {
    // 양방향 바인딩
    return <div>User Name: {this.props.userViewModel.name}</div>;
  }
}

export default UserView;

// View Model
import React from 'react';
import UserModel from '../models/UserModel';

class UserViewModel extends React.Component {
  constructor(model) {
    super();
    this.model = model;
  }

  get name() {
    return this.model.name;
  }

  set name(newName) {
    this.model.updateName(newName);
  }
}

export default UserViewModel;

MVP

1. 사용자의 action이 View를 통해 들어옴
2. View는 Presenter에게 데이터를 요청
3. Presenter는 Model에게 데이터를 요청
4. Model은 Presenter에서 요청받은 데이터를 응답
5. Presenter는 View에게 데이터를 응답
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냄

import React from 'react';
import UserModel from '../models/UserModel';
import UserView from '../components/UserView';

class UserPresenter extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      user: new UserModel('John Doe'),
    };
  }

  handleNameChange = (newName) => {
    this.state.user.updateName(newName);  // View Model을 업데이트
    this.forceUpdate();
  }

  render() {
    return (
      <div>
        // View에 전달 
        <UserView userName={this.state.user.name} />
        <button onClick={() => this.handleNameChange('Ahyeon')}>Change Name</button>
      </div>
    );
  }
}

export default UserPresenter;

그 외의 패턴

Flux 패턴

단방향 데이터 흐름을 유지하여 상태 관리를 간소화하는 데 중점을 둔 패턴

• Action: 사용자 또는 시스템 이벤트
• Dispatcher: 액션을 받아 상태를 변경하고, 등록된 스토어에 변경 사항을 전파
• Store: 애플리케이션의 상태를 저장하고 변경된 상태를 뷰에 전달
• View: 사용자 인터페이스를 표시하고, 스토어의 데이터를 표시

Redux 패턴

Flux 패턴을 기반으로 하되, 단순한 구조와 불변성을 강조하여 상태관리를 효과적으로 처리하는 데 중점을 둔 패턴

• Action: 상태 변경을 설명하는 객체
• Reducer: 현재 상태와 액션을 받아 새로운 상태를 반환
• Store: 애플리케이션의 상태를 저장하고, 리듀서를 통해 상태를 변경
• View: 상태를 표시하고, 스토어의 상태 변경을 구독하여 업데이트

Singleton 패턴

어플리케이션 전반에서 단일 객체 인스턴스만을 생성하고 이에 접근하는 패턴

Observer 패턴

객체 간 일대다 의존성을 정의하여 한 객체의 상태가 변경되면 종속 객체에 자동으로 알릴 수 있게 하는 패턴

뭔가 아픈 손가락이 된 sponsor me now,,

처음에는 호기롭게 시작했다. 한달까지는 그냥 vite 써보고, 결제 시스템 이해해보면서 재미있었다. 둘 다 늦장부리는 타입은 아니었기 때문에 진도도 금방뺄 수 있었다. 결제 도입하는 과정에서 vite가 업데이트되는 바람에 vite, node 싹 다 업데이트하고 고생을 하긴 했지만, 오랜만에 하루 내내 쓰는 에러여서 나름 재밌기도 하고 trigger가 필요해서 날 기다리는 백엔드도 적당히 부담스럽고 재밌었다. 하지만 마무리가 되어가는게 느껴질수록, 매듭지어질 수 있나에 대한 의문이 들었다. 회원가입, 게시글 작성, 결제, 결제 내역 불러오기 등 각 기능은 다 작동이 잘되는데, 유저가 사용하는 하나의 서비스라기엔 오묘하게 모든 곳에서 약간의 어색함이 있었다. 마무리 단계에서는 빨리 완성하고 싶은 마음이 더 컸는데, 처음으로 어떻게 매듭지어야될지 모르겠어서 쳐다만 보다가 그냥 블로그만 뒤적거리는게 반복되어갔다. 그러다가 다른 프로젝트를 시작하면서 기획회의를 하다가, 첫단추부터 잘못지어졌다는 걸 알았고, 포기 선언을 했다. 최소한 프로토타입은 만들어놓겠다고 했지만, 뭘 더 해야하는지도 모르겠어서 그냥 그대로 끝내게 되었다.

근데 사실 이게 애매한게, 초반에 기획한건 다 구현했다. 어쨌든 돌아가는 서비스다. 근데 매듭이 안지어진다. 어디서부터 잘못된건가..!

프로젝트에는 무엇이 필요한가

기획

프론트는 사용자와 가장 맞닿아있는 부분을 다뤄야하기 때문에, 사용자가 어떤 서비스를 왜, 어디에, 어떻게 쓸 것인지 이해하고 그에 맞춘 UX를 제공해야한다. 이 때 사용자의 페르소나, 요구사항, 시나리오 등등을 전부 생각하고, 해당 서비스가 왜 필요하고 어떻게 도움을 줄 수 있을지 정확하게 확정하고 가야한다. 적어도 와이어프레임을 그리는 과정에서 확정하며 서비스의 산출물을 예상할 수 있어야한다. 그런데 이번에는 조금 많이 달랐다. 사실 엘리스에서 제공해주는 주제도 없는 상황에서, '결제기능을 해보자'로 시작했고, 결제기능사용할꺼면 후원 서비스를 제작하자하고 출발했다. 와이어프레임도 늘 그랬듯이 그냥 즉석에서 그리고 바로 개발에 들어갔다. 기획보단 개발이 더 재밌으니까 빨리 떼버리겠다는 마음이 지배적이었단게 문제였다. 딱, 지금 막힌것과 똑같이 각 기능을 구현하는 페이지만 있고, 그 이후 마무리 설정이 전혀되어있지 않았다. 유저 시나리오가 전혀 없다보니 그냥 기능 위주로 페이지로 나와버린거다. 이제와서 기획을 엎고 가기엔 2주동안 마음이 떠버린 상태였다.

특히 이번에 동아리에서 PM과 함께 기획을 하면서 그 부족함을 계속 깨닫게 된다. 솔직히 엘리스에서 진행하면서 개인적으로 뭔가 백엔드를 수단으로 삼은 경향이 있다. 이런 기능이 필요하니까 만들어 달라고, 이런 데이터가 필요하니까 넣어달라고 프론트를 만드는 과정에서 계속 요청했다. 원래 그 기능 확정을 기획단계에서 마무리하고, 디자이너, 프론트와 백엔드는 각자 작업을 한 후 연결과정에서만 만났어야 했다. 그런데 PM, 디자이너, 프론트엔드를 내가 잡고 하다보니까 기능이 계속해서 변경되어야 했던거다. 그래서 모든 기획을 알고 있는 사람이 나밖에 없었고, 점점 더 부담스러웠던 것 같다. 이번에도 비슷한 결로 시작했다가 같은 문제가 생긴 셈이다. 프론트하고 싶으니까 기획은 대충하게 되고, 대충한 기획으로 붙들고 나가기가 쉽지 않다.

디자인

와이어프레임 기획을 제외하고 봐도, 디자인의 퀄리티면에서 부족함이 너무 보였다. 이게 화면이 큰 PC버전의 경우 조금 퀄리티가 덜해도 괜찮아보였는데, 웹뷰로 제작하다보니까 이 디자인의 부족함이 너무 눈에 보였다. 미묘한 차이가 바로바로 느껴져버리니까 퍼블리싱하고 싶은 마음도 점점 줄어들었다. 사실 눈에 보이는 산출물이 별로라는게 예상되다보니까 기획을 엎어도 똑같겠다는 마음이 크기도 했다. 이게 디자이너의 작업물을 한번 받아보니까 퀄리티 차이가 명확하게 드러나서 내가 안하고 사람을 구하는게 낫겠다는 생각을 하기 시작했다. 디자이너 뿐만 아니라 일단 기획자, 디자이너, 백엔드, 프론트엔드 각각 2명씩은 있어야 프로젝트를 진행하면서 발전을 할 수 있을거같다. 모두와 소통해야하는 프론트의 숙명,,

환경

엘리스에서 VM을 제공했고, 제공된 VM을 바탕으로 백엔드분들이 배포를 해줘서 나름 편하게 작업을 할 수 있었다. 하지만 둘이서 하다보니 AWS 프리티어를 사용해야했고, 프리티어여서 굉장히 느렸다. 백엔드분이 연구하다가 뭔가 가상 램을 설정해서 조금 편해지긴 했지만, 이미지 같은 경우 묘하게 싱크가 안맞았다. 사실 이 부분은 난 프론트만 하다보니까 못느꼈는데, 어쨌든 다음 프로젝트에서 배포를 어떻게 할 것인가에 대한 방법을 생각하고 참여해야함을 알 수 있었다. 이번에는 백엔드분이 알아서 다 해주셔서 나는 그냥 편하게 있었는데, 다른 프로젝트에도 이런 분이 있을지는 모르겠다. 이래서 그냥 백엔드하고 협업하는건 좀 어려울거같기도 하다. 나는 장기전을 바라봐야하는 사람인데 도중에 백서버가 자꾸 꺼지다보니까 뭔가 아쉬움이 크다. 다들 백 서버 유지 어떻게 하는거지..?

그냥 생각

단기성 프로젝트를 프론트 혼자 하다보니까 처음에는 재밌었는데, 이제 조금씩 한계가 보인다. 내가 작성한 코드에서 더 나아가지 못하는 느낌이 크게 든다. 그냥 돌아다니다가 리액트에서 탬플릿을 사용하는 프로젝트를 봤는데, 이해가 안가는거다. 거기서 좀 내 코드에 갇혀있기 쉽겠다는 생각을 하고, 다른 프로젝트의 코드를 둘러보기 시작했다. 그리고 리액트 스터디를 하면서, 초면인 개념이야 당연히 그냥 배웠는데, useState같은 아는 것들을 막상 까보니까 전혀 이해가 안가서 놀랐다. 이제는 프로젝트는 적당히 하고, 개념을 좀 채워나가고 싶다. 혼자서 책읽다가 스터디하면서 읽으니까 좀 더 자세히 읽게 되고 자존심 미쳐서 더 알아보고 싶어서 혼자 난리다. 난 분명 2개월동안 열심히 놀고 먹으려고 했는데, 왜 이러고 있는지 모르겠다.

사용자가 눈으로 보고 있는 화면의 높이(clientHeight)와 사용자가 스크롤해서 내린만큼의 높이(scrollTop)를 더한 값이, 전체화면에 대한 높이(scrollHeight)와 같으면 새로운 데이터를 받아오는 방식

window.addEventListner("scroll", infiniteScroll);
fetch(`${API}/posts?offset=${offset}&limit=${limit}`)
  .then(res => res.json())
  .then(res => {
    setState({
      products: res.products,
      offset: offset + limit,
      });
    });

const infiniteScroll = () => {
  const scrollHeight = Math.max(
    document.documentElement.scrollHeight,
    document.body.scrollHeight
  );
  const scrollTop = Math.max(
    document.documentElement.scrollTop,
    document.body.scrollTop
  );
  const clientHeight = document.documentElement.clientHeight;
  if (scrollTop + clientHeight === scrollHeight) {
    fetch(`${API}/posts?offset=${offset}&limit=${limit}`)
      .then(res => res.json)
      .then(res => {
        setState({
          products: [...products, ...res.products],
          offset: offset + limit,
        });
        setState({ isLoading: true});
        setTimeout(() => {
          setState({ isLoading: false });
        }, 350);
      });
    }

요소에 따른 데이터 불러오기

타겟 요소와 타겟의 부모 혹은 상위 요소의 뷰포트가 교차되는 부분을 비동기적으로 관찰하는 API, IntersectionObserver를 활용하여 화면에 지정한 타겟 요소가 보이면 데이터를 불러옴

function ProductPage () {
  const [ target, setTarget ] = useState(null);
// ...

  const _fetchProductItems = () => {
    const productItems = apiProductItems(itemLength);

    if (!productItems.length) {
      actions.isLoaded(dispatch)(false);
      return;
    }

    // ...
  };

  useEffect(() => {
    let observer;
    if (target) {
      observer = new IntersectionObserver(_onIntersect, { threshold: 1 });
      observer.observe(target);
    }

    return () => observer && observer.disconnect();
  }, [ target ]);

  const _onIntersect = ([ entry ]) => {
    if (entry.isIntersecting) {
      _fetchProductItems();
    }
  };

// ...

  return (
    <>
      // ...
      {state.isLoaded && <div ref={setTarget}>loading</div>}
    </>
  );
}

export default ProductPage;

useInfiniteQuery

tanstack-query의 useInfiniteQuery를 활용한 무한 스크롤

const {
  fetchNextPage,
  fetchPreviousPage,
  hasNextPage,
  hasPreviousPage,
  isFetchingNextPage,
  isFetchingPreviousPage,
  ...result
} = useInfiniteQuery({
  queryKey,
  queryFn: ({ pageParam }) => fetchPage(pageParam),
  initialPageParam: 1,
  ...options,
  getNextPageParam: (lastPage, allPages, lastPageParam, allPageParams) =>
    lastPage.nextCursor,
  getPreviousPageParam: (firstPage, allPages, firstPageParam, allPageParams) =>
    firstPage.prevCursor,
})

import PostItem from '../../../components/common/PostItem';
import styles from '../styles/Main.News.module.scss';
import {
  QueryFunction,
  QueryFunctionContext,
  useInfiniteQuery,
} from '@tanstack/react-query';
import { instance } from '@/api/instance';

interface PostsDataType {
  pages: {
    totalPage: number;
    currentPage: number;
    posts: {
      id: number;
      title: string;
      content: string;
      createdAt: string;
      updatedAt: string;
      authorId: number;
      viewCount: number;
      postImg: null | string;
    }[];
  }[];
}
export interface IRepository {
  total_count: number;
  incomplete_results: boolean;
  items: PostsDataType[];
  nextCursor?: string;
  prevCursor?: string;
}

type QueryKey = [string, string, string];

const News = () => {
  const page = 1;

  const fetchRepositories: QueryFunction<
    IRepository,
    QueryKey,
    unknown
  > = async ({ queryKey }: QueryFunctionContext<QueryKey>) => {
    const [, page, search] = queryKey;
    return await instance
      .get<IRepository>(
        `/post/list?page=${page}&limit=7${search && `&search=${search}`}`,
      )
      .then((res) => res.data);
  };
  const {
    fetchNextPage,
    fetchPreviousPage,
    hasNextPage,
    hasPreviousPage,
    isFetchingNextPage,
    isFetchingPreviousPage,
    ...result
  } = useInfiniteQuery<IRepository, Error, PostsDataType>({
    queryKey: ['postList', page.toString(), 'all'],
    queryFn: fetchRepositories,
    getNextPageParam: (lastPage) => lastPage.nextCursor,
    getPreviousPageParam: (firstPage) => firstPage.prevCursor,
  });

  console.log(result?.data);
  console.log(
    fetchNextPage,
    fetchPreviousPage,
    hasNextPage,
    hasPreviousPage,
    isFetchingNextPage,
    isFetchingPreviousPage,
  );
  return (
    <div className={styles.container}>
      {result?.data?.pages[0].posts.map((item) => (
        <PostItem key={item.id} data={item} />
      ))}
    </div>
  );
};

export default News;

이슈

데이터는 불러와지는데 페이지 이동은 어떻게 하는거지.. 데이터가 없으니까 된건지 확인할수가없다,,

결제 과정은 프론트에서 결제사에 금액과 정보 등을 가지고 요청을 보내고, 식별가능한 유니크 id를 받은 다음, 해당 id를 백에 전달한다. id를 받은 백은 해당 id를 결제사에 보내 유효한 결제 id인지 확인한 후, 해당 결제 정보를 받아와서 db에 저장한다.

왜 id만 주고 받을까

백은 어떤 경우든 프론트에서 완벽한 정보만 올 것이라고 생각해서는 안됨. 결제 id는 1000원으로 결제 해놓고 100000 만원이라고 서버에 보낼 가능성이 존재하기 때문에 안전하게 결제사에서 정보를 받아와야함.

왜 결제 정보를 결제사와 서버에서 저장할까

결제 내역 history를 제어하기 위함. 특정 기간의 결제 내역을 불러오거나, 특정 결제 대상 품목 필터링 등을 위해서 서버에 저장한다. 결제 내역을 서버에 저장하는게 추후 get할 때 결제사 개입 없어서 더 편함. 데이터 유지가능.

import postPaymentHistory from '@/api/post/postPaymentHistory';
import { useLoginStore } from '@/store';
import { useState } from 'react';
import styles from '../styles/UserId.PaymentSelect.module.scss';

const PaymentSelect = ({
  email,
  username,
  id,
  toggleIsOpenPaymentSelect,
}: {
  email: string;
  username: string;
  id: number;
  toggleIsOpenPaymentSelect: () => void;
}) => {
  const [selectedAmount, setSelectedAmount] = useState<null | number>(null);
  const [customAmount, setCustomAmount] = useState<undefined | number>();

  const handleSelectChange = (amount: number | null) => {
    setSelectedAmount(amount);
    setCustomAmount(0);
  };

  const handleCustomInputChange = (
    event: React.ChangeEvent<HTMLInputElement>,
  ) => {
    const inputValue = Number(event.target.value);
    if (isNaN(inputValue)) {
      alert('숫자를 입력해주세요.');
      setCustomAmount(undefined);
      return;
    } else {
      setSelectedAmount(null);
      setCustomAmount(inputValue);
    }
  };

  return (
    <div className={styles.container}>
      <h2>후원하기</h2>
      <label>
        <input
          type="radio"
          name="paymentAmount"
          value="10000"
          checked={selectedAmount === 10000}
          onChange={() => handleSelectChange(10000)}
        />
        10000원
      </label>

      <label>
        <input
          type="radio"
          name="paymentAmount"
          value="5000"
          checked={selectedAmount === 5000}
          onChange={() => handleSelectChange(5000)}
        />
        5000원
      </label>

      <label>
        <input
          type="radio"
          name="paymentAmount"
          value="3000"
          checked={selectedAmount === 3000}
          onChange={() => handleSelectChange(3000)}
        />
        3000원
      </label>

      <label>
        <input
          type="radio"
          name="paymentAmount"
          value="1000"
          checked={selectedAmount === 1000}
          onChange={() => handleSelectChange(1000)}
        />
        1000원
      </label>

      <label>
        <input
          type="radio"
          name="paymentAmount"
          value="custom"
          checked={selectedAmount === null && customAmount === undefined}
          onChange={() => handleSelectChange(null)}
        />
        직접입력
      </label>

      <input
        type="text"
        placeholder="원하는 금액 입력"
        value={customAmount}
        onChange={handleCustomInputChange}
        disabled={selectedAmount !== null}
      />
      <RequestPay
        payAmount={
          selectedAmount !== null && selectedAmount !== 0
            ? selectedAmount
            : Number(customAmount)
        }
        email={email}
        username={username}
        id={id}
        toggleIsOpenPaymentSelect={toggleIsOpenPaymentSelect}
      />
      <button className={styles.gray} onClick={toggleIsOpenPaymentSelect}>
        후원 취소
      </button>
    </div>
  );
};

export default PaymentSelect;

interface Response {
  apply_num?: number;
  bank_name?: string;
  buyer_addr?: string;
  buyer_email?: string;
  buyer_name?: string;
  buyer_postcode?: string;
  buyer_tel?: string;
  card_name?: string;
  card_quota?: number;
  custom_data?: string;
  imp_uid?: string;
  merchant_uid?: string;
  name?: string;
  paid_amount?: number;
  paid_at?: string;
  pay_method?: string;
  pg_provider?: string;
  pg_tid?: string;
  receipt_url?: string;
  status?: string;
  success: boolean;
}

interface RequestPayParams {
  pg: string;
  pay_method: string;
  merchant_uid: string;
  name: string;
  amount: number;
  buyer_email: string;
  buyer_name: string;
  buyer_tel: string;
  buyer_addr: string;
  buyer_postcode: string;
}

const RequestPay = ({
  email,
  username,
  payAmount,
  id,
  toggleIsOpenPaymentSelect,
}: {
  email: string;
  username: string;
  id: number;
  payAmount: number;
  toggleIsOpenPaymentSelect: () => void;
}) => {
  const code = import.meta.env.VITE_IAMPORT_CODE;

  const { loginUsername, loginEmail } = useLoginStore();

  if (!window.IMP || !code) return;
  const { IMP } = window;
  IMP.init(code);

  const today = new Date();
  const hours = today.getHours(); // 시
  const minutes = today.getMinutes(); // 분
  const seconds = today.getSeconds(); // 초
  const milliseconds = today.getMilliseconds();
  const makeMerchantUid = hours + minutes + seconds + milliseconds;
  const requestPay = () => {
    (
      IMP.request_pay as (
        params: RequestPayParams,
        callback: (rsp: Response) => void,
      ) => void
    )(
      {
        pg: `kakaopay.${import.meta.env.VITE_IAMPORT_KAKAOPAY_ID!}`,
        pay_method: 'card',
        merchant_uid: `IMP_${makeMerchantUid}`,
        name: `${loginUsername}의 ${username} 후원`,
        amount: payAmount,
        buyer_email: loginEmail!,
        buyer_name: loginUsername!,
        buyer_tel: '010-4242-4242',
        buyer_addr: '서울특별시 강남구 신사동',
        buyer_postcode: '01181',
      },
      (rsp: Response) => {
        if (rsp.success) {
          postPaymentHistory({
            sellerName: username,
            sellerEmail: email,
            impUid: rsp.imp_uid,
            sellerId: id,
          });
        } else {
          console.log('결제실패', rsp);
          toggleIsOpenPaymentSelect();
        }
      },
    );
  };

  return (
    <button className={styles.green} onClick={requestPay}>
      후원하기
    </button>
  );
};

결제를 취소해보자

프론트에서는 결제 내역의 유니크값을 가지고 백 서버에 delete 요청을 보냄. 백은 유니크값을 가지고 결제내역 데이터를 찾음. 유니크값 결제 id를 결제사에 보내 결제 취소요청을 보내고, 취소된 정보를 받아서 결제내역 데이터를 변경함.

왜 삭제하지 않고 변경을 하는가

결제 관련 데이터는 중요함. 환불 일시, 환불 금액, 환불 카드사 등 추후 문제가 될 수 있는 부분을 가지고 있어야함

생각하기

전의 모든 trigger는 테스트 버전이다. 사업자등록 필요한데, 법적인 문제가 걸려있어 발들이기 어려움. 유저에게 노출가능한 값은 무엇이 있는가. 특정 정보만으로 결제사로 들어가 접근할 수 없도록 보안이 필요함. 프론트에서 해줄 수 있는 보안 강화는 무엇이 있을까. 수수료는 어디서 얼마나 빠져나가야하는가.

많은 사람들이 null을 리턴하는 것과 false를 리턴하는 것이 같다고 생각한다. 그들은 매우 비슷하지만, React가 동작하는 방법과 관련하여 몇 가지 차이점이 존재한다.

React로 개발을 할때, 특정 조건에 따라 다른 컴포넌트를 보여주기 위한 조건부 렌더링을 흔히 사용한다. 이러한 경우, 컴포넌트가 렌더되지 않아야함을 명확하게 나타나길 원할 것이다. 여기서 null과 false가 사용된다. 둘 다 컴포넌트가 렌더링되는 것을 막지만, 그들 사이에 차이점이 있다.

Returning null

컴포넌트가 null을 리턴할때, React에게 그 컴포넌트의 어느것도 DOM에서 렌더하지 말라고 말하는 것이다. 이것은 상태를 충족하지 않았을때 어느것도 렌더링하지 않길 원하거나 특정 상태에 따라 컴포넌트를 조건부로 렌더링하길 원할 때 유용할 수 있다.

const Greeting = (props) => {
  if (!props.name) {
    return null;
  }

  return <h1>Hello, {props.name}!</h1>;
};

만약 name prop이 제공되지 않았다면, 컴포넌트는 null을 리턴하고 h1 태그가 렌더링되는 것을 막을 것이다. 만약 제공된다면, h1 태그는 렌더링된다.

Returning false

컴포넌트가 false를 리턴할때, null과 같이 컴포넌트를 DOM의 어디에도 렌더링하지 말라고 말한다. 그러나, 중요한 차이점이 있다. false 리턴은 컴포넌트가 미래에 업데이트되는 것을 막는다. 이것은 React가 false를 전체 DOM으로부터 제거하라는 의미인 컴포넌트 언마운트의 신호로 해석하기 때문이다.

const Button = (props) => {
  if (!props.onClick) {
    return false;
  }

  return <button onClick={props.onClick}>Click me</button>;
};

onClick prop이 제공되지 않는다면, 컴포넌트는 false를 리턴하고, button 태그가 렌더링되는 것을 막을 것이다. 만약 제공된다면, 특정 클릭 핸들러를 가진 button이 렌더될 것이다.

false 리턴하는 것은 업데이트가 되어야할때도 업데이트를 막는 것과 같은 의도치 않은 결과를 가져올 수 있기 때문에 중요하다. 이런 이유로, 미래 업데이트에 영향을 주고 싶지 않을 때는 null을 사용해야 더 안전하다.

컴포넌트의 렌더 방법으로 false를 리턴하는 것은 상태 업데이트나 API 요청과 같은 side effect를 가지지 않았을 때만 유용하다. 만약 side effect를 가지고 false를 리턴한다면, 이런 side effect는 기대하지 않은 행동을 초래할 수 있다.

Returning Fragment

Fragment는 컴포넌트를 렌더링할 때 불필요한 DOM 요소를 생성하지않는다. DOM 구조에 영향을 주지 않고 요소를 함께 그룹화하는 데 사용한다. Fragment는 DOM에 렌더되지 않고 Fragment의 자식요소들은 렌더되므로 사용하는 케이스가 다르다.

결론?: false로 하면 이상한 경우가 있으니 null 사용해라

그런 경우가 어떤 경우인가

shouldComponentUpdate 어떤 컴포넌트의 render()가 자신이 다시 호출될 필요가 없음에도 호출되는 것을 막기위해 사용하는 것 반환값이 true이면 render가 호출되고, false이면 render가 호출되지 않음

shouldComponentUpdate(nextProps: Props, nextState: State) {
  return this.props.title !== nextProps.title || this.state.input !== nextState.input
  }

Reference

https://tech.jotform.com/return-null-vs-return-false-in-react-826d8abcc429 https://junghyeonsu.com/posts/react-fragment-vs-null/ 모던 리액트 Deep Dive

PoC(Proof of Concept). 어떤 기술을 도입할 때 왜 도입했는지, 어떤 효과가 가대되는지에 대해 토론하자. 기술 도입을 위한 개념 증명, 논리 확보를 위해 자료를 수집하고 정리하기. 서로 토론하면 더 좋다. => 제대로 알고 라이브러리를 선택해라!!

나의 라이브러리 선택 기준

이건 정말 할 말이 없지만.. 지금까지 내 라이브러리 선택 기준 1순위는 로고가 얼마나 귀여운가였다. 진짜 그러면 안되는걸 알면서도 뭔가 로고가 좀 올드하거나 화질이 저세상이면 손이 안 갔다. 일단 라이브러리 성능에 대한 기준이 없다보니 그냥 귀여운 라이브러리는 줍줍해서 쓰려고 했다. react-query가 이 분야의 정점인데, 꽃모양이 너무 귀여워서 쓰고야말겠다는 생각이 날 지배했다. 그러다가 아다리가 맞게도 적합한 이슈가 생긴 시점에 그냥 선택한 react-query가 해결해주게 되면서, 라이브러리의 성능에 대한 관심이 생겨났다. 아무튼 그래서 내 최애 라이브러리는 Storybook.. 사실 아직도 귀여워.. 이건 그냥 추측인데 만약 react보다 express 로고가 더 귀여웠다면 난 백엔드 했을지도..?

react-query나 storybook 같은 경우는 그냥 로고가 귀여워서 언젠가 쓰고 싶은 라이브러리였고, 그래도 나름 생각해서 선택하긴했다. 일단 라이브러리쓰기 전에 상태관리조차도 제대로 모를때 prop주기 귀찮으니까 특정 페이지 안에서만 상태관리를 하고 싶어서 Context API를 사용했다. 그러다가 /:id search로 Context API를 쉽게 대체할 수 있었다. 그리고 로그인 상태를 전역관리하고 싶어서 라이브러리를 찾아봤고, login이나 logout에서 뭔가 액션이 있다고 판단해서 redux-Toolkit을 사용했다.(redux 대체된다길래 모른척했는데 다시 공부하러가야한다) 그리고 액션이 없는 것들은 간단하게 상태를 저장하고 바꾸는정도만하면 되겠다 싶어서 recoil을 사용했다. 그리고 최근에는 recoil보다 zustand가 가볍다길래 zustand를 사용했다.

무맥락에 논리를 넣어보자

Context API

React에서 지원하는 context를 사용하기 위한 API이다. React에서 지원하기 때문에 별도의 패키지를 다운받을 필요없이 상용가능하며, 러닝커브가 작다. 그러나 하나의 상태만 저장가능하며, 상태값이 변경되면 Provider로 감싼 모든 자식 컴포넌트가 리렌더링된다.

Redux

Flux 아키텍처 모델을 기반으로 하는 중앙 집중식 상태 관리 솔루션을 사용. Action이 발생하면 Dispatcher에서 이를 해석한 후 Store에 저장된 정보를 갱신하고, 그 결과가 다시 View로 전달된다. 복잡한 로직을 처리하기 위한 강력한 미들웨어를 지원하지만 더 많은 보일러플레이트 코드가 발생할 수 있으며 러닝커브가 있다.

MobX

상태를 프록시 객체로래핑하여 직접 객체를 다루지 않고, 프록시를 통해 작업을 수행하므로 중첩된 객체의 상태 관리에 유용하다. 일반적으로 중첩된 객체의 상태를 관리하려면 상태를 복사하고, 속성을 수정하고, 수정한 상태를 다시 덮어쓰는 과정이 필요한데, MobX에서는 프록시를 통해 상태를 직접 변경할 수 있어 중첩 객체 상태 관리가 편해진다.

Recoil

Context API 기반으로 페이스북에서 만든 함수형 컴포넌트에서만 사용 가능한 전역 상태관리 라이브러리로, react 내장 hooks를 사용하는 방식과 크게 다르지 않아 러닝커브가 작다. redux의 thunk나 saga같은 미들웨어를 사용할 필요없이 비동기 처리가 내장되어 있으며 보일러 플레이트가 작다. 그러나 클래스형 컴포넌트에서 사용할 수 없다.

Zustand

React Hooks를 기반으로 하여 함수형 컴포넌트에 쉽게 통합되며, 가볍고 번들 크기가 작다.

기준을 세워보자

• 커뮤니티 크기 Redux > MobX > Recoil = Zustand > Context API
• 러닝커브 Redux > MobX > Recoil > Zustand > Context API
• 프로젝트 크기 큰 프로젝트: Redux = MobX > Recoil > Zustand = Context API 중간 프로젝트: MobX > Recoil = Zustand > Redux > Context API 작은 프로젝트: Zustand > Recoil > MobX > Redux > Context API
• 설치 및 설정 간편성 Zustand > Recoil > Context API > MobX > Redux
• 배우기 쉬운 정도 Zustand > Recoil = Context API > MobX > Redux
• 미들웨어 및 고급 기능 지원 Redux > MobX > Recoil > Zustand = Context API
• 중첩된 객체 또는 복잡한 상태 구조 관리 MobX > Recoil > Redux = Zustand > Context API
• 함수형 및 클래스형 컴포넌트 모두 지원 MobX > Recoil > Zustand > Context API > Redux
• 동기 및 비동기 업데이트 지원 Recoil > Zustand > Redux > MobX > Context API
• 성능 Recoil > Zustand > MobX > Redux > Context API
• 비동기 처리 지원 Recoil > Zustand > Redux > MobX > Context API
• 기존 프로젝트와의 호환성 Redux > MobX > Zustand > Recoil > Context API

최신 라이브러리 톺아보기

Recoil과 Jotai는 Context와 Provider, 그리고 훅을 기반으로 가능한 작은 상태를 효율적으로 관리하는데 초점을 맞춘다. Zustand는 리덕스와 비슷하게 하나의 큰 스토어를 기반으로 상태를 관리하는 라이브러리로 하나의 큰 스토어가 클로저를 기반으로 생성되어 이 스토어의 상태가 변경되면 상태를 구독하고 있는 컴포넌트에 전파해 리렌더링을 알리는 방식이다.

Recoil

리액트에서 훅의 개념으로 상태 관리를 시작한 최초의 라이브러리 중 하나 최소 상태 개념인 Atom을 처음 리액트 생태계에 선보임 메타 팀에서 주도적으로 개발 selector 등 다양한 비동기 작업을 지원하는 API를 제공하여 미들웨어 불필요 그러나 아직 실험 단계로, 안정성, 성능, 사용성 보장 불가능

Jotai

Recoil의 atom 모델에 영감을 받아 만들어진 상태 관리 라이브러리 작은 단위의 상태를 위로 전파할 수 있는 구조인 bottom-up 상향식 접근법을 취함 리액트 Context의 불필요한 리렌더링 문제를 해결하고자 설계되었으며 메모이제이션이나 최적화를 거치지 않아도 리렌더링이 발생되지 않도록 설계됨.

Zustand

리덕스에 영감을 받아 하나의 스토어를 중앙 집중형으로 활용해 이 스토어 내부에서 상태를 관리함

결론

리덕스가 리액트 상태 관리를 지배하다가, 최근에는 여러가지 라이브러리들이 등장했다. 각 상태 관리 라이브러리가 상태를 관리하는 방식에는 조금씩 차이가 있지만, 리액트에서 리렌더링을 일으키기 위한 방식은 제한적이기 때문에 어떠한 방식으로 상태를 관리하든지 간에 리렌더링을 만드는 방법은 거의 동일하다. 따라서 각 라이브러리별로 특징을 잘 파악하고, 현재 애플리케이션이 상황과 철학에 맞는 상태 관리 라이브러리를 적절하게 사용하여 효율적인 애플리케이션을 만들자.

Webpack과 vite

'create-react-app' 하나면 리액트 프로젝트 뚝딱이었지만, 최근에는 vite를 사용한다는 말이 들려서 webpack, babel 등등 이들이 그래서 뭔 역할을 하는지 궁금해졌다. 일단 대략적인 차이점은 webpack은 빌드를 하면서 모든 모듈을 하나의 번들로 제공하고, vite는 개발 서버에서 모듈을 실시간으로 번들링하고, 프로덕션 빌드 시에는 더 작은 코드 스플릿 번들을 생성하여 빠른 반응성을 제공한다는 점. 한 모듈 리플레이스먼트를 지원하고, esbuild를 사용한다고 하는데 webpack도 떼지못한 내가 알아보기엔 외계어다..

React 직접 구성하기

일단 webpack의 역할부터 체감해야한다.

1. package.json 파일 생성

npm init -y

노드 프로젝트를 시작.

2. Babel 설치

npm install --save-dev @babel/core @babel/preset-env @babel/preset-react babel-loader

// .babelrc
{
  "presets": ["@babel/preset-env", "@babel/preset-react"]
}

지바스크립트의 서로 다른 문법간의 오류를 하나로 통합해줄 바벨의 모듈을 설치 JSX와 ES 이상의 문법을 다른 브라우저가 이해할 수 있도록 ES5 문법으로 변환시켜줌 빌드 시에만 필요하기 때문에 devDependencies로 설치

• @babel/core: 바벨의 핵심 기능을 담당
• @babel/preset-react: 리액트의 JSX를 자바스크립트 코드로 변환
• @babel/preset-env: ES6 이상의 문법을 ES5로 변환해주는 프리셋

3. Webpack 설치

npm install --save-dev webpack webpack-cli webpack-dev-server html-webpack-plugin css-loader style-loader

// webpack.config.js
const HtmlWebpackPlugin = require("html-webpack-plugin");
const path = require("path");

module.exports = {
  entry: "./src/index.tsx",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist"),
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: { loader: "babel-loader" },
      },
      { test: /\.css$/, use: ["style-loader", "css-loader"] },
    ],
  },
  resolve: {
    extensions: [".js", ".jsx"],
  },
  plugins: [new HtmlWebpackPlugin({ template: "./public/index.html" })],
  devServer: {
    static: {
      directory: path.join(__dirname, "dist"),
    },
    hot: true,
    open: true,
  },
};

• webpack-dev-server: 개발 모드에 필요한 서버를 구동해줌. 컴퓨터의 메모리를 빌려 웹팩을 작동시키고 임시 서버를 띄움
• css-loader, style-loader: css 문법을 자바스크립트로 변환해주는 역할 css-loader가 변환한 파일을 index.html의 '