May the code be with you

[Typescript] Typescript Infer / 조건부 타입(Conditional Types)

code walker — Sun, 23 Jun 2024 23:49:53 +0900

infer keyword 란?

infer 키워드는 TypeScript에서 조건부 타입(Conditional Types)과 함께 사용되어 특정 타입의 정보를 추론할 수 있게 합니다.

주로 타입의 일부를 추출하거나 변환하는 데 유용합니다.

infer 키워드를 사용하면 타입을 변수처럼 선언하고 조건부 타입 내에서 이를 활용할 수 있습니다.

infer 키워드를 사용하는 것이 유리한 상황은 주로 복잡한 타입을 다룰 때입니다.

infer는 타입 시스템을 보다 강력하고 유연하게 만들어 주며, 타입 추론을 자동화함으로써 코드의 유지보수성을 높여줍니다.

infer 키워드는 조건부 타입 내부에서만 사용할 수 있습니다.

컨디셔널 타입의 참 부분에만 infer된 타입 변수를 사용할 수 있다. 거짓 부분에서 쓰려고 하면 에러가 발생합니다.
왜 그런지는 생각해 보면 당연합니다.
infer를 통해서 추론할 수 있다면 참으로, 없다면 거짓으로 가게 되는데 infer를 통해서 타입을 추론할 수 없다면 해당 타입을 결정할 수 없다. 따라서 infer를 통해서 타입을 결정할 수 있는 참 부분에서만 infer를 통해 만들어진 타입 변수를 사용할 수 있는 것입니다.

1. 간단한 infer 예시

type Unpack<T> = T extends (infer U)[] ? U : T;

// string[] 타입의 요소를 추출
type Test1 = Unpack<string[]>; // string

// 그냥 타입을 반환
type Test2 = Unpack<number>; // number

위 코드에서 Unpack 타입은 제네릭 타입 T를 인수로 받습니다.

T가 배열 타입인지 확인하고, 배열이라면 요소 타입(U)을 추출합니다. 그렇지 않다면 T 자체를 반환합니다.

2. Function return Type 추출

type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;

// 함수 타입에서 반환 타입 추출
type Test3 = ReturnType<() => string>; // string

type Test4 = ReturnType<(x: number) => boolean>; // boolean

이 예제에서 ReturnType 타입은 함수 타입 T의 반환 타입 R을 추출합니다. T가 함수 타입이 아닌 경우, 기본적으로 any 타입을 반환합니다.

3. Promise 내부 Type 추출

type Awaited<T> = T extends Promise<infer U> ? U : T;

// 프로미스 타입에서 내부 타입 추출
type Test5 = Awaited<Promise<string>>; // string

type Test6 = Awaited<number>; // number

여기서는 Awaited 타입이 Promise 타입의 내부 값을 추출합니다.

T가 Promise 타입이라면 내부 타입 U를 반환하고, 그렇지 않다면 T를 그대로 반환합니다.

4. 외부 라이브러리에 types를 제공 안해주는 경우 (타입 추출 )

function getProfileO(person:{
    name:string;
    age:number;
    hobbies:[string, string];
}){
    return `${person.name}은 ${person.age}살이고 ${person.hobbies.join(" 와 ")}가 취미입니다.`
}

const me={
    name:"남광민",
    age:30,
    hobbies:["JS", "TS"],
}
// me.hobbies의 타입이 string[]으로 추론되어 타입 에러 발생
getProfile(me);

위 코드는 me.hobbies의 타입이 string[]으로 추론되어 타입 에러 발생합니다.

type GetFirstArgumentType<T> = T extends (arg: infer U, ...args:any) => any ? U : never;

const me:GetFirstArgumentType<typeof getProfile>={
    name:"남광민",
    age:30,
    hobbies:["JS", "TS"],
}

getProfile(me);

그냥 Person 타입을 새로 정의해 주는 방법도 있겠지만 서드파티 라이브러리의 코드를 다 파악해서 타입을 새로 정의하는 것은 쉽지 않습니다. 이런 경우 infer를 사용한 GetFirstArgumentType<T>와 같은 타입으로 쉽게 함수 인자 타입을 추론해 줄 수 있습니다.

마치며

infer 타입은 사실 TS를 하면서 자주 마주할 일은 없는 타입 입니다.
자주 사용한다면 오히려 뭔가 코드가 이상해지고 있다는 이야기일지도 모릅니다.
하지만 외부 함수를 사용할 때 함수의 인자나 리턴 타입 추론, 재귀적인 타입 추론 등 다른 타입에서 어떤 일부 타입을 뽑아서 사용해야 할 때 매우 유용하게 사용할 수 있습니다. 이런 활용법을 알아두면 나중에 유용하게 쓸 수 있을 것입니다.

[React] 이제는 써야한다.Suspense , ErrorBoundary feat:(Apollo Clients)

code walker — Wed, 20 Mar 2024 23:32:54 +0900

개요

현재 회사에서 맡고있는 프로덕트는 어드민 페이지를 관리 하고있는데, 어드민의 UI/UX가 대부분 filtering 하는 검색박스와, 이를 결과로 보여주는 AgGrid 라는 라이브러리의 table을 사용하고있습니다.

추가로 GraphQL을 사용하기에 , Apollo-client를 사용하고 , Gql query 통해 error , loading 그리고 data state를 관리하고 있습니다. 위에 말했다시피 data를 AgGrid table로 그리는 페이지가 대다수였기에, Aggrid table 컴포넌트에서 제공하는 error, loading props를 넘겨주면 각 상황에 맞는 UI가 유저에게 그려지고 있습니다.

하지만 어느 프로젝트나 시간이 지나면 그렇듯 프로덕트의 범위가 커지고, 어드민의 페이지가 늘어나고 기획 및 디자인 범위가 늘어날수록, 단순히 table만 그리는게 아닌 새로운 컴포넌트도 많이 도입이 되고 있었습니다.

국내 및 해외 빅테크의 비동기 통신처리를 리액트에서 어떻게 하는지 유튜브나 블로그 포스팅글을 자주 보곤했는데, React 18의 Suspense 그리고 ErrorBoundary를 통해 비동기 통신 하는것을 추천 하는 글을 많이 보고 Suspense의 매력을 알아채고 기회가 되면 회사 프로젝트에 사용을 해봐야지 라는 생각을 갖고 있었습니다.

자 그럼 우선 Suspense가 비동기 통신에 어떤 이점이 있고 , React 16 , 17 version 의 Suspense과 18 version 의 Suspense의 차이를 알아보고, Apollo에서 제공하는 useSuspenseQuery와 어떻게 사용하는지 작성해보겠습니다.

1. Why Suspense ?

React의 Suspense는 컴포넌트의 로딩 상태를 React 자체에서 처리할 수 있게 해주는 기능입니다.

이로 인해 데이터를 불러오는 비동기 로직을 쉽게 관리할 수 있으며, 이는 컴포넌트의 로딩 상태나 오류 상태를 처리하는 새로운 패턴을 제공합니다. Suspense는 React 16.6에서 처음 도입되었고, React 18에서는 Suspense 기능이 확장되어 더 많은 유형의 비동기 작업을 처리할 수 있게 되었습니다.

Suspense의 장점

1. 코드 분할을 쉽게 관리: Suspense를 사용하면 코드 분할(Code-Splitting)과 같은 비동기 작업을 쉽게 처리할 수 있습니다. 이는 애플리케이션의 로딩 시간을 줄이고 성능을 향상시킵니다.

2.일관된 로딩 상태 처리: Suspense는 로딩 인디케이터 같은 UI를 쉽게 통합할 수 있게 해줍니다. 이를 통해 비동기 로딩 상태를 일관되게 관리할 수 있습니다.

3.컴포넌트 추상화: 데이터 로딩 로직을 컴포넌트 외부로 분리함으로써 컴포넌트를 더 깨끗하고 관리하기 쉽게 만들 수 있습니다.

4. 동시성 모드(Concurrent Mode)와의 통합: React 18에서는 Suspense가 Concurrent Mode와 결합하여, 여러 비동기 작업을 동시에 처리하면서도 사용자 인터페이스를 즉시 반응하게 할 수 있습니다.

2. React 16~17 의 Suspense와 React 18 Suspense

React 16, 17 의 Suspense

주로 코드 분할을 위한 것으로 사용되었습니다. 컴포넌트가 로딩 중일 때 다른 컴포넌트로 대체하는 방식으로 작동했습니다. 주로 React.lazy와 import()를 사용하여 동적으로 컴포넌트를 로드하는 데 사용되었습니다.

Suspense의 핵심은 Promise를 throw 하는 것입니다 . Promise가 resolve(성공) 하거나 reject(실패) 할 때까지 컴포넌트 트리의 실행을 연기 시킵니다.

컴포넌트 트리의 실행이 연기되는 동안 컴포넌트 트리는 UI에서 숨겨집니다. DOM 트리에서 삭제되는 것이 아니라 해당 컴포넌트에 display: none 스타일을 추가하는 것입니다.

React 16,17 에서의 Suspense 사용 예제

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    // Displays <Spinner> until OtherComponent loads
    <React.Suspense fallback={<Spinner />}>
      <div>
        <OtherComponent />
      </div>
    </React.Suspense>
  );
}

React 18 의 Suspense

컴포넌트 트리의 실행이 연기되는 동안 해당 컴포넌트는 DOM 트리에 존재하지 않습니다.

실행이 완료되지 않는 컴포넌트는 커밋 되지 않아, 따라서 컴포넌트가 완료되고 DOM 트리에 배치되며 브라우저 화면에 업데이트되기 때문에 라이프사이클 이벤트가 불일치하는 일이 발생하지 않습니다.

Suspense는 데이터 로딩을 포함한 더 광범위한 비동기 작업을 지원합니다. 동시성 모드와의 통합을 통해 더 부드러운 사용자 경험을 제공합니다. Suspense는 이제 렌더링을 "중단"할 수 있으며, React는 우선순위에 따라 다른 작업으로 전환할 수 있습니다. 새로운 데이터 가져오기 라이브러리와의 통합을 위한 API가 도입되었습니다. 이를 통해 컴포넌트가 데이터를 필요로 할 때까지 데이터 로딩을 지연시킬 수 있으며, 이는 서버 사이드 렌더링(SSR)에서도 유용하게 사용될 수 있습니다. 더 나은 에러 핸들링을 제공하며, Suspense boundary 내에서 발생하는 오류를 쉽게 관리할 수 있습니다.

기존 SSR 방식 문제점

1. HTML을 렌더링 하기 전에 app에 필요한 모든 데이터를 가져와야한다. 서버에서 HTML 렌더링을 시작하려면 모든 데이터가 준비되어 있어야 한다. 즉, 데이터가 수집되지 않으면 HTML 렌더링을 시작하지 못해 클라이언트에 어떠한 HTML로 전송할 수 없다는 것을 의미한다. 만약 초기 화면 일부에 필요한 데이터가 준비되는 시간이 늦어지면 초기 화면의 나머지 HTML 렌더링도 늦어지며 전송도 지연된다.

2. hydrate를 시작하기 전에 필요한 모든 JavaScript 코드가 로드되어야 한다. 서버에서 렌더링된 HTML이 전달되면 정적인 HTML을 상호작용 가능하게 하기 위해 이벤트 핸들러를 연결해야 한다. 이때 브라우저 컴포넌트에 의해 생성된 컴포넌트 트리가 서버에서 생성된 트리와 일치해야 한다. 일치하지 않는다면 React는 HTML과 JavaScript 코드를 매치할 수 없다. 이 때문에 hydrate를 진행하기 전 모든 JavaScript를 로드해야 하는 것이다. 화면의 일부분(컴포넌트)에 상호작용할 로직이 많이 존재할 때, 이에 따른 JavaScript 로직을 다운로드하는데 시간이 많이 걸릴 경우 비교적 상호작용 로직이 적은 화면(컴포넌트) HTML에도 hydrate를 시작할 수 없다.

3. 상호작용을 시작하기 전, 모든 HTML에 hydrate가 완료되어야 한다. hydrate가 시작되면 React는 hydrate가 완료될 때까지 멈출 수 없으며 다른 작업을 할 수 없다. 즉, 화면 일부에 필요한 코드 다운로드가 느리다면 navigation 바 또는 사이드 바와 같은 부분도 hydrate가 되지 않아 해당 페이지에서 벗어나거나 다른 컨텐츠와 상호작용할 수 없다. 만약 느린 네트워크를 사용하는 사용자가 있다면 그 사용자는 HTML만 보고 있을 뿐 어떠한 작업도 할 수 없다는 것을 의미한다.

3. Apollo client (useSuspenseQuery)와 함께 쓰는법

이제 실제프로젝트에서 어떻게 Apollo와 어떻게 사용했는지 작성해보려 합니다.

프로젝트내 아폴로 버전이 3.7 이였습니다. 공식문서상 리액트의 Suspense 기능을 사용하려면 기존에 자주 사용하던 useQuery , useLazyQuery가 아닌 useSuspenseQuery를 사용해야하는데 , 3.8 버전부터 사용이 가능하여 package 업그레이드를 우선 진행했습니다.

우선 Apollo 공식문서 예제 코드입니다.

import { Suspense } from 'react';
import {
  gql,
  TypedDocumentNode,
  useSuspenseQuery
} from '@apollo/client';

interface Data {
  dog: {
    id: string;
    name: string;
  };
}

interface Variables {
  id: string;
}

interface DogProps {
  id: string
}

const GET_DOG_QUERY: TypedDocumentNode<Data, Variables> = gql`
  query GetDog($id: String) {
    dog(id: $id) {
      # By default, an object's cache key is a combination of
      # its __typename and id fields, so we should always make
      # sure the id is in the response so our data can be
      # properly cached.
      id
      name
      breed
    }
  }
`;

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Dog id="3" />
    </Suspense>
  );
}

function Dog({ id }: DogProps) {
  const { data } = useSuspenseQuery(GET_DOG_QUERY, {
    variables: { id },
  });

  return <>Name: {data.dog.name}</>;
}

위 코드예시를 보면 useQuery나 useLazyQuery에서 제공하는 boolean 타입의 loading state는 useSuspenseQuery 에서 반환하지 않습니다.

useSuspenseQuery를 호출하는 컴포넌트가 데이터를 가져올 때 항상 suspends 상태가 되기 때문입니다. 이에 대한 함의는 렌더링될 때, 데이터가 항상 정의되어 있다는 것입니다! Suspense 패러다임에서는, 기존에 컴포넌트가 스스로 렌더링해야 했던 로딩 상태를 대체하는 fallback 들이 대기 중인 컴포넌트의 바깥에 존재합니다.

useSuspenseQuery hook 은 네트워크 요청을 시작하고 요청이 진행되는 동안 호출한 컴포넌트를 대기 상태로 만듭니다. 이를 사용하는 동안 렌더링하는 동안 React의 Suspense 기능을 활용할 수 있게 해주는 useQuery의 Suspense 준비된 대체재로 생각할 수 있습니다.

ErrorBoundary와 함께 사용하는법

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback;
    }

    return this.props.children;
  }
}

function App() {
  const { data } = useSuspenseQuery(GET_DOGS_QUERY);
  const [selectedDog, setSelectedDog] = useState(
    data.dogs[0].id
  );

  return (
    <>
      <select
        onChange={(e) => setSelectedDog(e.target.value)}
      >
        {data.dogs.map(({ id, name }) => (
          <option key={id} value={id}>
            {name}
          </option>
        ))}
      </select>
      <ErrorBoundary
        fallback={<div>Something went wrong</div>}
      >
        <Suspense fallback={<div>Loading...</div>}>
          <Dog id={selectedDog} />
        </Suspense>
      </ErrorBoundary>
    </>
  );
}

여기에서, 우리는 ErrorBoundary 컴포넌트를 사용하고 Dog 컴포넌트의 바깥에 배치합니다. 이제, Dog 컴포넌트 내부의 useSuspenseQuery 훅이 에러를 던질 때, ErrorBoundary가 이를 잡아내고 우리가 제공한 fallback 요소를 표시합니다.

useSuspenseQuery는 데이터를 가져오는 동안 대기 상태가 되기 때문에, useSuspenseQuery를 사용하는 컴포넌트 트리는 각각의 useSuspenseQuery 호출이 이전 호출이 완료될 때까지 시작할 수 없는 " waterfall"을 일으킬 수 있습니다. 이는 부모 컴포넌트에서 useBackgroundQuery로 데이터를 가져오고, 자식 컴포넌트에서 useReadQuery로 데이터를 읽음으로써 피할 수 있습니다.

도움 될만한글: Suspense 를 무분별하게 사용하고 있진 않는지?

https://happysisyphe.tistory.com/54

[Typescript] Typescript satisfies

code walker — Mon, 15 Jan 2024 22:45:07 +0900

개요

2년전, 타입스크립트를 처음에 접할땐 interface , type 키워드만알아도 거의 개발하는데 무방했지만, 실무에서 타입스크립트와 리액트로
개발하다보면 TS의 Util을 활용을 하면 훨씬 더 편하고, 확장성 좋은 강력한 type safe 기능을 발휘 할 수 있습니다.
그래서 작년에 TS의 Util 관련하여 블로그 포스팅한게 있습니다. 지금도 헷갈리거나 기억이 안날때 가끔 제가 쓴
블로그 보면서 참고하는데요.

이번엔 타입스크립트의 "satisfies" 키워드를 포스팅 해보겠습니다.
TS를 극한으로 쓰시는분들이 아니면 이 키워드는 생소(?) 할것같은데요. (저는 그랬습니다.)

satisfies 키워드가 무엇이고 언제 쓰이면 유용할까요?

일단 개인적으로 저는 타입스크립트의 Type safe역할도 그렇지만, 미리 Interface 나 type을 작성하고 타입 지정을 해주면 제가 작성해놓은 type에 맞게끔 자동완성 기능을 정말 애용하는 편입니다.
그리고 또한 그 타입의 맞는 method 또한 자동으로 완성되죠. 아래의 예시를 보면서 satisfies를 적용하고나서와 하기전을 비교해보겠습니다.

TypeScript의 satisfies 키워드는 TypeScript 4.9에서 도입된 새로운 기능으로, 주로 타입 체크를 강화하고 코드의 의도를 명확히 하기 위해 사용됩니다. 이 키워드는 특정 변수가 특정 타입을 '만족(satisfy)'하는지를 확인하는 데 사용됩니다. 기본개념 variable satisfies Type 구문을 사용하면, variable이 Type의 모든 요구 사항을 충족하는지 확인할 수 있습니다. 이는 주로 다음 두 가지 상황에서 유용합니다:

1. 타입 가드: 변수가 특정 타입을 만족하는지를 런타임에 확인합니다.
2. 타입 정제: 특정 조건에서 변수의 타입을 더 구체적인 서브타입으로 좁혀 나갑니다.

Example.1 atisfies 적용전

type ProfileType = {
  name:string;
  age:string | number;
}

const profile:ProfileType = {
  name:'kwangmin',
  age:30
}

위 예시는 전혀 문제가없습니다.

age 쪽을 보면 string과 number 유니온 타입을 받는데요. 아래의 이미지를 보면 profile의 name은 string의 하나의 타입을 가집니다.
그래서 profile 객체의 name의 키값에 접근할때는 string method를 자동완성으로 보여주고있습니다.
하지만 유니온 타입은 age의 접근할때는 number의 method를 제대로 불러오질 못하고있습니다.

반대로 age를 string의 값인 "30"으로 바꾼다고 해도 똑같이 method 자동완성을 제대로 못하고있습니다.

Example.1 satisfies 적용후

type ProfileType = {
  name:string;
  age:string | number;
}

const profile = {
  name:'kwangmin',
  age:30
} satisfies ProfileType

satisfies 키워드를 선언하면 사용하는 타입의 따라 모든 메소드를 자동완성 해주고있습니다. 간단하죠?

Example 2.

const profile:Record<string,number> = {};

profile.any = 10;
profile.any2 = 20;

scores의 객체의 키값이 string인 와이드한 타입이기때문에 선언이 되어있지도 않는 any, any2의 접근을 해도 타입에러를 내뱉지 않습니다. 만약 객체의 키값도 자동완성 기능과 타입 체크를 원한다면 여기서도 satisfies를 사용 할 수 있습니다.

사실 satisfies 를 사용 하지않고도 아래처럼 키값을 정해줄 수 도있습니다. 이런식으로 해도 타입가드 역할을 할 수있습니다.
오히려 아래는 키 name값을 직접 미리 타입으로 선언해줄수있어서 아래의 방법도 괜찮습니다.

type Key = 'name' | 'age'

const profile:Record<Key,number> = {};

profile2의 키값 자동완성은 완성될수없습니다. 왜냐하면 키값을 그저 string의 타입을 갖고오기때문이죠.

as 와 satisfies 차이

as

as 키워드 as 키워드는 타입 단언(type assertion)에 사용됩니다. 이는 개발자가 TypeScript 컴파일러에게 "이 변수를 내가 지정한 타입으로 처리해 달라"고 요청하는 것과 같습니다. 컴파일러는 이 단언을 신뢰하고 해당 타입에 맞게 코드를 처리합니다. 하지만 실제 런타임에서 변수의 타입이 단언한 타입과 다를 경우에도 TypeScript는 이를 감지하지 못하고, 오류가 발생할 수 있습니다. 즉, as 키워드는 컴파일 시간에만 영향을 미치며 런타임 타입 검사는 하지 않습니다.

satisfies

반면, satisfies 키워드는 주로 개발 중 타입의 호환성을 검사하기 위해 사용됩니다. satisfies는 변수가 특정 타입을 "만족하는지(satisfies)" 검사하고, 만족하지 않으면 컴파일 시점에 오류를 발생시킵니다. 이는 타입 안정성을 강화하고, 코드가 명시된 타입 계약을 정확히 준수하도록 보장합니다. satisfies는 타입 단언과 달리 런타임에 영향을 미치지 않으며, 주로 타입 검사와 문서화에 유용합니다.

타입 검증 vs. 타입 단언: as는 타입 단언으로, 개발자가 컴파일러에게 타입을 강제로 지정하게 합니다. 반면, satisfies는 타입이 특정 조건을 만족하는지 검증합니다.

안전성: satisfies는 타입 불일치 시 컴파일 오류를 발생시켜, 코드의 타입 안전성을 높입니다. as는 런타임 오류를 유발할 수 있는 위험을 갖고 있습니다.

용도: as는 주로 타입 정보가 부족한 상황에서 사용되며, satisfies는 타입 계약을 확인하고 문서화하는 데 유용합니다.

satisfies를 사용함으로서 더욱 강력한 타입세이프 기능을 활용하고 더 편한 개발을 할 수 있을것같습니다!

Reference

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

코드 가독성에 대해 (feat: KISS, Boy scout rule)

code walker — Sun, 14 Jan 2024 22:17:55 +0900

개요

코딩을할때 어떤 방법이 100% 옳다라는 정답은 없지만 코드의 가독성에 대해 생각하고 작성 한다면 추후에 같은 코드를 보면서 개발을할때 훨씬 수월하게 할 수 있다는 생각은 100% 맞는 말 같습니다.

이 포스팅은 사내 그룹스터디 할때 토픽이 되었던 주제인데, 좋은 글인거같아 정리삼아 포스팅을 하려고 합니다.

아래의 포스팅 전체의 내용을 다루는것보다, 사내 스터디를 할때 기억에 가장 남은것들만 우선 정리한 포스팅 입니다.

1. 코드의 가독성은 왜 높아야할까?

어떤 feautre을 개발한다고 칩시다.

저는 프론트엔드 개발자이니까 보통 기획과 디자인 그리고 백엔드 개발자에게 디자인 리뷰 , API interface등 리뷰를 받고 개발을 진행 한적이 많은데, 리뷰를 받고 feature 개발 하기까지의 2주라는 시간이 소요된다고 가정하에, 이 2주동안은 feature의 대한 이해, 왜 개발을 하는지? 어떤 기획의 의도가 있는지를 파악을 한 상태에서 개발을 할것입니다.

예를들어 변수명 및 함수명을 마감기한이란 압박때문에 5분 조차 고민 안하고 생각나는 대로 지었고, 어떻게 개발 완료를 해서 배포까지 완로 되었습니다.

하지만 한달 후 , 다른 feature 개발 후 전에 개발하던것에서 에러가 터지거가, 추각개발건이 있다고 가정하에 변수명과 함수명을 대충 지었다는 이유로 전체적인 로직을 한번 쭉 훑어봐야하는 불상사가 생길 수 있습니다.

또 다른 이슈는 제가 휴가를 가거나 Day off인날은 다른 개발자가 제 코드를 무슨 생각으로 짰는지 파악할때 변수명과 함수명을 잘 지었으면 코드 파악하는것이 훨씬 수월 했겠죠.

5분 생각해서 변수 명을 고민하거나 적절한 주석을 다는 것으로 다른 개발자(미래의 자기 자신도 포함)가 1시간 고민하는 일을 막을 수 있을지 모릅니다. 중요한 것은 단기적이고 개인적인 생산성이 아니라 상품의 라이프 사이클 기간에 걸친 팀 전체의 생산성입니다

코드의 가독성을 높게 코드를 작성하는 방법론은 매우 많지만 아래의 간단한 예제를 통해서 변수명이 왜 중요한지 파악해보겠습니다.

  function checkLegalDrinkingAge(age:number):boolean{
    if(age > 19){
      return true;
    }else {
      return false;
    }
  }

사실 위의 코드예시는 함수명과 age라는 파라미터를 보고 "19" 라고 되어있는 부분이 어떤 값인지 유추 할 수 있습니다.

하지만 19를 변수로 따로 관리 해서 예를들어 const LEGAL_DRINKING_AGE = 19 라는 constant 로 따로 관리하면 어떤 의도로 19를 작성했는지, 또는 19가 어떤 의미인지 더 잘 파악 할 수 있겠네요.

코드의 가독성을 중시해야 할지 결정하는 기준은 코드를 읽고 해석하는 데 드는 시간과 코드를 작성하는 데 드는 시간을 비교하는 것입니다.

2. 프로그래밍 원칙

견고하고 가독성 높은 코드를 작성하기 위해서는 프로그래밍 원칙에 따르는 것이 유용한 경우가 많습니다. 본 장에서는 코드의 가독성을 고려할 때 특별히 중요한 것뿐만 아니라, 혹시 과도하게 적용해도 부작용이 별로 없는 프로그래밍 원칙 5개가 참고 포스팅에 있지만 저는 2개정도만 정리하려고합니다.

2-1. The boy scout rule

The Boy Scout Rule 이 원칙은 "코드를 변경할 때마다 더 깔끔하게 만들어라"라는 생각을 기반으로 합니다. 보이스카우트 운동의 창시자 Robert Baden-Powell의 격언에서 영감을 받아 Robert C. Martin이 소프트웨어 개발에 적용한 원칙입니다.

구체적인 예시로, 코드를 수정하는 과정에서 변수명을 더 명확하게 변경하거나, 필요한 주석을 추가하고, 불필요한 코드를 제거하는 것이 포함됩니다. 이 원칙의 핵심은 코드를 만질 때마다 전반적인 코드베이스의 질을 향상시키려는 노력입니다. 예를 들어, 복잡한 switch 문에 새로운 케이스를 추가하는 대신, 전략 패턴(strategy pattern)을 사용하여 리팩터링하는 것이 이 원칙을 따르는 좋은 예시가 될 수 있습니다.

2-2. KISS (Keep It Simple Stupid)

이 원칙은 "항상 간단하게 유지해라"는 의미로, 복잡성을 최소화하고 단순성을 유지하는 것을 강조합니다.

원래는 군사 장비의 설계 원칙으로 사용되었으나, 소프트웨어 개발에도 적용됩니다. KISS 원칙은 특히 기능과 구현 방식을 단순하게 유지하는 것을 지향합니다. 복잡하고 고도로 추상화된 코드보다는 이해하기 쉽고, 유지 관리가 용이한 코드를 선호합니다. 이 원칙의 핵심은 목적과 수단의 구분입니다. 프로그래밍 기법과 패러다임, 설계 방법은 코드의 가독성과 견고함을 향상시키기 위한 수단이어야 하며, 그 자체가 목적이 되어서는 안 됩니다. 예를 들어, 리액티브 프로그래밍이나 다른 고급 기법을 단지 그것이 "아름답다"거나 "일관성이 있다"는 이유로 사용하는 것은 KISS 원칙에 어긋납니다.

이 두 원칙은 모두 코드의 가독성과 유지 보수성을 높이는 데 중점을 두고 있으며, 좋은 소프트웨어 개발 관행의 일부로 널리 인정받고 있습니다.

KISS의 간단한 예로 자바스크립트 삼항연산자로 예를 들겠습니다.

const age = name === 'john' ? 20 : name === 'tom' ? 19 : name === 'zed' ? 30 : null;

이러한 삼항 연산자가 있다고 가정해보면, 이 정도 deps의 조건이면 그냥 if else문을 적나라하게 쓰는게 훨씬 가독성이 좋습니다..

Simple Stupid 처럼요.

다른 개발자가 저 코드를 파악하려면 예를들어 10분 걸릴것을, 간단한 if else문으로 작성하면 3분도 안되는 시간에 파악 할테니까요.

아래 처럼 말이죠.

if (name === 'john') {
    return 20;
} else if (name === 'tom') {
    return 19;
} else if (name === 'zed') {
    return 30;
} else {
	return null;
}

저는 2년차때쯤엔 코딩테스트를 보다가 구현사항을 10줄이 넘게 코드 작성을 했었는데, 다른 분은 2줄이면 구현을 해버리는것을 본 뒤로

2줄로 구현하는게 가독성이 좋고, 간결해서 구현사항에 더 유리할 줄 알았었습니다. 하지만 지금은 그게 좋지만은 아닌것 같습니다.

특히 코딩테스트는 개인이보는거지만 실무에선 협업, 즉 다른 사람들과 항상 함께 같이 일을 하니까요.

사내 컨벤션이 있다면 컨벤션에 최대한 따라주면서, 컨벤션이 잘못된거같거나,개선사항이 있으면 좋을것 같은것들은 항상 팀원들과 얘기하면서 코드 가독성을 개선하면서 개발을 해야 할것 같습니다.

KISS reference

https://medium.com/@ksekwamote/keep-it-simple-stupid-how-it-applies-in-javascript-113b1c4e77a8

https://www.linkedin.com/pulse/best-practices-writing-javascript-code-dry-kiss-yagni-emmanuel/

참고한 포스팅: https://engineering.linecorp.com/ko/blog/code-readability-vol1

[React] useDebounce custom hook 으로 성능향상 해보기 (feat: Debounce)

code walker — Wed, 13 Sep 2023 00:19:27 +0900

Debounce 란?

짧은 시간내에 연속 된 함수 및 event 호출시, 호출 되는 모든 함수를 바로 처리하지않고 정해진 딜레이 이후에 한번만 처리 하는 패턴 입니다.

Debounce는 왜 필요할까?

1. 네트워크 요청의 함수나 전반적인 성능을 향상 시키기 위해서 가장 많이 쓰입니다.

2. 비용절약 측면에서도 Debounce가 필요한데요, 예를들어 어떠한 서비스앱이 유료 API가 사용되고있는데 , API의 호출 횟수의 따라 비용이 나간다면 debounce 를 사용하여 네트워크 요청의 횟수를 줄일 수 있습니다.

Use case

1. input의 입력과 동시에 네트워크 요청을 통해 검색 결과를 가져올때

(유튜브에서 React와 Debounce 관련 설명 영상의 예시가 거의 위의 사용사례로 강의를 합니다.)

2. 스크롤 / 리사이즈 바탕으로 작업을 할때

3. 문서 편집 자동저장

간단한 예시를 통해 debounce의 필요성과 재사용성이 높게끔 리액트 커스텀 훅으로 예제를 만들어보겠습니다.

코드 예제

// Main.jsx

import React, { useEffect, useState } from 'react';

export default function Main() {

  const [countries, setCountries] = useState([]);
  const [input, setInput] = useState("");

  const getCountries = async () => {
    try {
      const countriesData = await fetch(`https://restcountries.com/v3.1/name/${input}`);
      const json = await countriesData.json();
      setCountries(json);
    } catch (error) {
      console.log(error);
    }
  };

  useEffect(() => {
    if(input) getCountries();
  }, [input]);

  return (
    <div>
      <input
        type="text"
        value={input}
        onChange={(e) => setInput(e.target.value)}
        placeholder='나라를 검색해보세요.'
      />
      {countries?.length === 0
      	? <strong>나라가 없습니다.</strong>
        : countries?.map((item)=>(
          <div key={item.common}>
          	{item.name.common}
          </div>
      ))}
    </div>
  )
}

코드 관련해서 간단하게 설명하자면, restcountries 에서 국가의 정보 관련된 API를 가져옵니다. 그리고 input의 value로 국가를 검색합니다.

더 쉽게 말해, input에 입력과 동시에 결과를 input의 입력값에 따라 검색 결과를 가져온다고 보면 될것같습니다.

Debounce 를 적용하기전의 모습

debounce를 적용하기전, 아래의 gif를 통해 검색창에 'korea'를 검색하는것과 'korea'를 검색했을때 네트워크 통신이 몇번이나 이뤄지는지 한번 보겠습니다.

위 예제를 통해 확인해보면 'korea'의 한글자 마다 네트워크 요청을 보내고있는데요, 이런식으로 input의 값이 바뀔때마다 fetcher 함수를 호출 하고있습니다. 예제의 방법보다는, 유저가 검색창의 입력이 일어나고 fetcher 함수를 호출 하기 전까지 텀(딜레이)가 있다면 효율적인 함수 호출이 가능해집니다.

그래서 이런 부분을 보다 효율적으로 바꾸기 위해 debounce를 적용 하면 성능이 개선 될 수 있습니다.

useDebounce Custom Hook 만들어보기

// useDebounce.js

import { useEffect, useState } from "react";

//delay 같은경우 보통 500ms 을 사용한다고 합니다.
function useDebounce(value, delay = 2000) {
  const [debounceVal , setDebounceVal] = useState(value);

  useEffect(()=>{
    const handler = setTimeout(()=>{
      setDebounceVal(value);
    },delay);
    return () => {
      clearTimeout(handler);
    }
  },[value,delay])
  return debounceVal;
}

export default useDebounce;

우선 리액트 네이밍 컨벤션 , hook 같은 경우 앞에 'use..~' 가 붙으니 useDebounce 라는 커스텀 훅 파일을 하나 생성을 해줍니다.

위의 코드를 간단하게 설명하자면, 두가지의 인자를 custom hook에 받습니다. 첫번째 인자는 value를 받는데 , 이전 Main.jsx 에서

input state 값을 인자로 받습니다. 그리고 두번째는 setTimeOut의 delay의 값을 넣어주는데 , 기본값을 보통은 500ms로 지정하지만

저는 확실하게 debounce가 되는지를 위해 2000ms 으로 지정 했습니다.

useDebonce hook에 또 다른 state를 생성 하는데 전달받은 value의 인자값을 debounceVal의 state에 초기값 설정을 해줍니다.

그리고 마지막으로 useEffect로 전달받은 인자 value의 값이 업데이트 될때마다 setTimeOut의 함수가 호출이 되어, setDebounce를 통해 최신 value(debounceVal)를 리턴 해줍니다.

Debounce 를 적용하고나서의 모습

useDebounce의 delay 인자의 초기값을 2000ms로 해서 꽤 시간이 걸리네요ㅎㅎ..

그래도 debounce를 적용하기전에는 한글자 한글자 마다 네트워크 요청이 이뤄졌었는데 , useDebounce 커스텀 훅으로 유저의 이벤트가 끝나고 2000ms이 지난 후 한번만 'korea' 네트워크 요청을 하는것을 볼 수 있습니다.

Reference

https://www.youtube.com/watch?v=gwIkg1acujU&t=97s

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

[Monorepo] 모노레포는 멀티레포로부터 어떻게 구원을 해줄까?feat:Turborepo

code walker — Wed, 6 Sep 2023 00:48:37 +0900

모노레포를 알아보기전에 우선 모놀리식 , 멀티레포를 알아야 합니다.

모노레포의 등장배경과 모노레포의 장점을 파악하려면 기존의 프로젝트 구성에 어떤 단점이 있는지 알아봐야합니다.

모놀리식이란?

모놀리식 애플리케이션은 모듈화 없이 모든 구성 요소가 한 프로젝트 안에 통합된 소프트웨어 애플리케이션을 이야기합니다. DB 커넥션을 맺고, 데이터를 요청하며, 화면을 그리는 로직이 한 프로젝트 안에 구현된 초기 웹 서비스를 모놀리식 애플리션으로 볼 수 있습니다.

모놀리식의 장점

소수의 개발자가 빠르게 개발할 수 있음.

모놀리식의 단점

1. 관심사 분리가 어려워서 설계, 리팩토링 어려움

2. 매번 거대한 프로젝트를 배포 해야함.

3. 일부분의 에러가 전체 서비스에 영향을 줄 수 있음.

멀티레포란 ?

폴리레포(Poly repo) 라고도 부릅니다. 멀티레포란, 만약 모노레포가 지금 어떤것인지 모른다면 현재 사용되고있는 프로젝트는 멀티레포로 되어있을 가능성이 큽니다. 프로젝트별로 레파지토리를 생성하여 만든 프로젝트를 멀티레포라고 합니다.

각각의 프로젝트가 자신만의 고유의 저장소를 가지게 되고 , 다른 프로젝트와 의존성을 전혀 갖고 있지 않아, 독립적으로 빠르게 개발이 가능합니다.

그리고 독립적으로 관리가 되기 때문에 크기가 가벼우므로 프로젝트 관리 또한 쉬운 편 입니다.

멀티레포의 장점

1.독립성과 격리: 각 리포지토리는 독립적으로 관리되므로 하나의 리포에서 발생한 문제가 다른 리포에 영향을 미치지 않습니다. 이는 다수의 독립적인 프로젝트나 서비스를 관리해야 하는 경우 유용합니다.

2. CI/CD 파이프라인 분리: 멀티 리포에서는 각 리포의 CI/CD 파이프라인을 분리하여 관리할 수 있으므로, 특정 프로젝트에 대한 배포 및 테스트 프로세스를 개별적으로 조정할 수 있습니다.

멀티레포의 단점

1.코드 중복성: 공통 코드나 라이브러리가 여러 리포지토리에 중복해서 들어갈 수 있습니다. 이로 인해 코드 변경 사항을 유지하거나 버그를 수정할 때 중복된 작업이 필요할 수 있습니다.

2.관리 오버헤드: 멀티 리포에서는 각각의 리포지토리를 별도로 관리해야 하므로, 리포지토리 생성, 업데이트, 보안 관리 등에 추가적인 관리 오버헤드가 발생할 수 있습니다.

3.한가지 feature을 개발을 위해 여러 레파지토리에 merge를 해야합니다.

멀티레포의 단점에 대해 Turborepo에서 든 예시를 보면 멀티레포의 단점의 대해서 더욱 이해가 잘 되었습니다.

예를 들어, App, Doc 및 shared-utils 세 개의 별도 저장소가 있다고 가정해보겠습니다.

App 과 Doc 모두 npm 패키지로 게시되는 shared-utils에 의존합니다. shared-utils에서 버그가 발생하여 앱과 문서에 중요한 이슈가 발생한다고 가정해봅시다. 이러한 경우 다음과 같은 과정이 필요합니다.

1. shared-utils에서 오류를 수정하는 커밋 생성

2. shared-utils 내에서 npm에 게시하기 위한 게시 작업 실행

3. App 내에서 shared-utils 종속성의 버전을 올리는 커밋 생성

4. Doc 내에서 shared-utils 종속성의 버전을 올리는 커밋 생성

5. 위 4단계를 거쳐야 App , Doc이 버그가 수정된 버전으로 배포를 완료 할 수 있습니다.

App 이나 Doc이 shared-utils에 의존하는 수가 늘어날수록 이 프로세스가 더 오래 걸릴 수 있으며 매우 번거로울 수 있습니다.

모노레포의 등장

우선 간단하게 모노레포의 정의를 설명하자면 두 개 이상의 프로젝트 코드를 하나의 버전 관리 저장소(repository)에서 관리하는 방법을 말합니다. 멀티레포처럼 독립적으로 관리 되는것이 아닌, 멀티레포의 반대로 모두 하나의 레파지토리에서 모든것이 관리가 됩니다. (최상위 폴더부터 트리구조로 서비스 폴더가 구성된다고 합니다.)

Google, Facebook, Microsoft, Uber, Airbnb 그리고 Twitter 등 여러 글로벌 기업들은 자신들의 운영 전략 아래 대규모 모노레포를 이미 운영하고 있다고 합니다.

프로젝트를 진행할때 규모가 작으면 굳이 모노레포 구성의 프로젝트 세팅을 할 필요는없곘지만, 서비스가 거대해지면

코드내에서 공유되는 코드 그리고 의존성 패키지들이 분명히 점차 많이 생겨날것입니다.

모노레포의 장점

1. 코드 공유와 재사용: 모노리포에서는 모든 애플리케이션 및 모듈이 하나의 코드베이스에서 관리됩니다. 이로 인해 코드 공유와 재사용이 용이해집니다. 공통 라이브러리, 유틸리티 함수 및 컴포넌트를 쉽게 다른 프로젝트에서 공유하고 활용할 수 있습니다.

2. 테스트 및 통합 용이성: 모노리포에서는 모든 코드가 함께 있으므로 서로 다른 애플리케이션 간의 테스트 및 통합이 용이합니다. 코드 변경 사항이 다른 애플리케이션에 어떤 영향을 미치는지 빠르게 확인할 수 있습니다.

3.배포 및 릴리스 관리 단순화: 모노리포에서는 하나의 릴리스 프로세스를 사용하여 모든 프로젝트를 동시에 배포할 수 있습니다. 이로 인해 배포 및 버전 관리가 단순화되며, 다수의 애플리케이션 간의 버전 호환성을 보다 쉽게 유지할 수 있습니다.

4.NPM에 배포할 필요가없어서 의존성관리가 쉬움

이 외에도 의존성 관리가 쉽고 , 여러 프로젝트팀 간의 협업이 수월 해집니다.

모노레포의 단점

1. CI 속도 저하 가능성이 있음.

2. 무분별한 리팩토링의 가능성이 있음

모노레포를 사용해야 할때는 언제?

1. 기존에 있는 서비스와 새로 개발 될 서비스가 비슷해서 로직관련한 코드의 중복성이 생길 수 있을때 모노레포를 사용하면 좋습니다. 예를들어 PC 페이지 모바일 페이지로 나뉘어지고 기능은 같을때 모노레포로 구성 하는것이 좋습니다.

2. 멀티레포처럼 여러 레파지토리를 확인하면서 코드를 파악하지 않고 한눈에 하나의 저장소에서 여러 프로젝트를 파악 해야할때도 모노레포로 구성 하는것이 좋습니다.

3. NPM과같은 디펜던시뿐만 아니라 전체적인 개발자의 코드 configuration 파일들도 모노레포에서 설정을 할 수 있기때문에

eslint, prettier 과 같은 세팅을 동일하게 줄 수 있어서 통일감 있는 코드를 작성할 수 있을때 , 또한 모노레포로 구성 하는것이 좋습니다.

FYI , 마치며

이런 모노레포를 구성해주는 도구도 있습니다.

Yarn , Turborepo ,, Nx , npm , pnmp 등 여러가지가 있습니다.

개인적으로 저는 최근에 사이드프로젝트를 Next.js13으로 구성했었던적이 있어서 앞으로 Next.js 13을 멀티레포로 구성할때는

Vercel에서 관리 되는 Turborepo를 사용해서 사이드프로젝트를 진행 해볼 예정입니다 :)

각각의 프레임워크, 라이브러리에 맞는 모노레포의 구성을 도와주는 도구가 있으니 참고하시면 될것같습니다.

Reference

https://turbo.build

Turbo

Turbo is an incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust.

turbo.build

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

https://www.youtube.com/watch?v=Ix9gxqKOatY&t=408s

[Yarn Berry] Yarn Berry가 node_modules의 문제를 어떻게 해결할까?

code walker — Tue, 5 Sep 2023 01:56:54 +0900

개요

2년차 주니어 프론트엔드 개발자로 일하면서 , 요즘 드는 생각이 리액트, 뷰, 앵귤러 같은 프레임워크의 변화를 지켜보고

어떤 부분이 더 좋고, 어떤 부분이 더 편리하게 변했는지 공부하는거도 중요하지만 이런 프레임워크 및 라이브러리를 설치해주는 의존성 및 관리하는것은 node_modules 입니다.

이제는 리액트 , 자바스크립트 등의 기술도 물론 중요하지만 이런 의존성 패키지의 Background에 대해서도 deep하게 공부 해야할것 같다는 생각이 들었습니다.

그래서 node_modules의 단점을 극복해줄 Yarn berry를 알아보면서 node_modules의 단점을 공부하기위해 포스팅을 하려고합니다.

Package 란?

우선 패키지란 무엇인지 간단한게 알아보겠습니다.

모듈(Module)

모듈은 Node.js 애플리케이션을 작은 조각으로 분할하는 방법입니다. 모듈은 코드를 논리적으로 그룹화하고 해당 모듈에서 정의된 변수, 함수, 클래스 등을 내보내거나 가져와서 재사용할 수 있게 해줍니다. Node.js는 CommonJS 스펙을 따르므로, require 함수를 사용하여 모듈을 불러올 수 있습니다.

패키지(Package)

패키지는 Node.js 애플리케이션에서 사용되는 외부 라이브러리나 모듈의 집합입니다. 패키지는 package.json 파일에 정의되며, 이 파일은 프로젝트의 의존성 및 설정 정보를 포함합니다. 패키지 관리자인 npm(Node Package Manager) 또는 yarn을 사용하여 패키지를 설치하고 관리할 수 있습니다.

node_modules 의 문제점

간단하게 node_modules의 대표적인 단점들을 알아보겠습니다.

의존성 버전 충돌

프로젝트의 여러 의존성 패키지가 서로 다른 버전의 라이브러리를 요구할 때, node_modules는 버전 충돌 문제가 발생할 수 있습니다. 이로 인해 프로젝트의 안정성과 유지 보수가 어려워질 수 있습니다.

패키지 설치 시간

의존성 패키지를 설치할 때 node_modules 폴더는 상당한 용량을 차지하고 설치 시간이 오래 걸릴 수 있습니다.

프로젝트 폴더 가독성

node_modules 폴더는 프로젝트의 루트 디렉토리에 생성되며, 프로젝트 코드와 함께 저장되어 프로젝트 구조를 복잡하게 만들 수 있습니다.

이 외에도 비효율적 의존성 검색, 유령 의존성 등이 있습니다. 토스팀 에서 잘 설명해놓은게 있으니 링크 참고해서 꼭 확인해보시는걸 추천 드립니다.

참고로 Yarn과 Npm은 다운로드를 받았는지만 검사하고 , 의존성 모듈들이 "잘" 다운로드가 됐는지는 확인을 안한다고 합니다.

Yarn berry의 등장

우선 Yarn berry는 node_modules와 node에 내장된 의존성 관리 없이 의존성을 관리하는게 주요한 기능 입니다.

Yarn berry는 Yarn version2 입니다. 이전 버전의 Yarn과 비교하여 다음과 같은 주요 변경 사항이 있습니다.

PnP (Plug'n'Play) 모드

Yarn Berry의 가장 큰 변경 사항 중 하나는 Plug'n'Play(PnP) 모드의 도입입니다. PnP 모드는 Node.js 프로젝트에서 의존성을 관리하는 새로운 방식입니다. 이전에는 node_modules 폴더에 의존성 패키지를 설치하고 사용했지만 PnP 모드에서는 이러한 패키지를 별도의 폴더에 설치하고 가상 파일 시스템을 통해 Node.js에 제공합니다. 이로써 의존성 충돌과 패키지 버전 관리가 향상되며, 더 빠른 설치와 실행이 가능해집니다.

PnP (Plug'n'Play) 사용법

NPM에서 최신버전의 Yarn을 내려받고, 버전을 Berry로 설정하면 Yarn Berry를 사용 할 수 있습니다.

$ npm install -g yarn
$ cd ../path/to/some-package
$ yarn set version berry

그러고 PnP 모드에서 yarn install을 이용하여 의존성을 다운로드 했을때 기존의 node_modules랑은 다른 모습울 볼 수 있습니다,

Yarn berry를 이용하면 node_modulues가 디렉토리에 없는걸 확인 할 수 있습니다.

대신 .yarn/cahce 폴더에 의존성의 정보가 저장이 되고 pnp.cjs 라는 생소한 파일이 하나 있을건데요.

pnp.cjs 파일에 의존성을 찾을 수 있는 정보가 기록 됩니다.

출처:우아한 테크 유튜브

Zero Install (feat: zipfile)

출처: 우아한 테크 유튜브

위 디렉토리 구조를 보면 zip으로 묶인 라이브러리가 저장된 .yarn/cache 폴더를 볼 수 있습니다.

Yarn PnP 시스템에서 각 의존성은 Zip으로 관리됩니다. 이후 .pnp.cjs 파일이 지정하는 바에 따라 동적으로 Zip 아카이브 내용이 참조 됩니다.

Zip 아카이브의 의존성의 장점은

1. 더 이상 node_modules의 구조를 생성할 필요가 없기때문에 설치가 빨리 완료됩니다.

2. 각 패키지는 버전마다 하나의 Zip 아카이브를 가지기 떄문에 중복해서 설치 되지 않습니다. 또한 Zip이 압축되어있음을 고려할때 스토리지 용량을 크게 아낄 수 있습니다.

속도비교

출처:우아한테크 유튜브

결론

NPM

npm은 아무래도 가장 오래 사용되고 있기도 하고 그만큼 reference가 많아서 trouble shooting 하기도 좋은 패키지 매니지먼트 입니다. reference가 많고 안정된걸 지향 한다면 추천 드립니다.

PNPM

pnpm은 npm보다는 성능이 좋지만 reference npm보다는 없기 때문에 npm 만큼의 trouble shooting을 기대하긴 어려울것같습니다.

Yarn (Classic)

Yarn version 1 같은 경우에는 2.0 버전이 나오면서 2020년도 부터 더 이상 ver1은 개발하지않고 유지보수 모드로 들어갔다고 합니다.

장기적인 프로젝트를 진행한다면 Yarn ver 1 사용은 지양 하는게 좋을것같습니다.

Yarn Berry

npm 만큼의 reference는 없지만 CI / CD 및 배포속도 패키지의 용량 고려 등의 이유로 충분히 도입 해볼만 하다고 생각합니다.

Reference

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

https://toss.tech/article/node-modules-and-yarn-berry

node_modules로부터 우리를 구원해 줄 Yarn Berry

토스 프론트엔드 레포지토리 대부분에서 사용하고 있는 패키지 매니저 Yarn Berry. 채택하게 된 배경과 사용하면서 좋았던 점을 공유합니다.

toss.tech

https://www.youtube.com/watch?v=Ds7EjE8Rhjs&t=77s

[React] 왜 Create React App 대신에 Vite를 사용할까?

code walker — Wed, 23 Aug 2023 10:39:39 +0900

개요

2년전쯤 리액트를 처음 배울때는 CRA 를 통해 React app을 만들어서 공부를 했었는데요 , 요새는 vite를 더 추구하는것같습니다. 그래서 Vite를 사용한지도 약 1년정도 된거같은데, 체감상으로도 확실히 빌드속도 ,세팅속도 그리고 가장 매력적이였던건 개발 중 코드를 수정하고 브라우저에 반영하기까지의 속도가 CRA에 비해 굉장히 빨랐습니다.

어떤 점이 Vite가 CRA보다 궁금해서 검색을 하다가 설명이 너무 길지도 않고 Vite의 핵심만 담겨있는 포스트를 발견해서 번역 및 참고 해서 포스트를 하려고합니다.

Reference:https://makimo.com/blog/why-we-use-vite-instead-of-create-react-app/

Why we use Vite instead of Create React App — Makimo – Consultancy & Software Development Services

Create React App is for many developers the default option since they have never checked out other JavaScript build tools. But there are better alternatives.

makimo.com

CRA가 느린 이유는 무엇인가요?

CRA는 내부적으로 웹팩(Webpack)을 사용합니다. 웹팩은 애플리케이션 코드 전체를 번들로 묶은 후 서버에서 제공합니다. 큰 코드베이스의 경우 개발 서버를 실행하는 데 더 많은 시간이 걸리며 변경 사항이 반영되는 시간도 오래 걸립니다.

대다수의 프로젝트는 대표적인 프론트엔드 애플리케이션 개발 라이브러리인 React의 창시자들이 주도하는 Create React App (CRA)에 의존하고 있습니다.

CRA는 React 문서에서 기본 선택지이며, 많은 개발자들에게는 다른 JavaScript 앱 빌드 도구를 확인해보지 않아서 기본 선택으로 남게 되었습니다. 그러나 더 나은 대안들이 있습니다.

Makimo에서는 많은 애플리케이션을 Vite로 전환하고 있습니다.

아래에서는 이 작업을 진행한 이유를 설명하겠습니다. 또한 Create React App의 한계에 대해서도 논의하겠습니다.

CRA는 JavaScript 프로젝트를 구성하기 위한 매우 간단한 도구이며, 단일 명령으로 작동하는 작업을 생성할 수 있습니다. 그러나 구성 및 번들러 사용에 대한 제약으로 인해 Vite가 더 나은 선택임이 입증되었습니다.

Vite 대비 Create React App의 장점

Create React App (CRA)은 가장 인기 있는 번들러 중 하나인 Webpack을 구성할 필요 없이 사용할 수 있게 해주는 확장 프로그램입니다. CRA는 Webpack에 새로운 기능을 추가하지 않습니다. 오히려 가능한 선택지의 수를 제한하여 초보 개발자들을 위한 확실한 솔루션으로 만들어 줍니다.

빌드 속도

CRA를 Vite로 변경한 주된 이유는 속도입니다. Vite는 esbuild 번들러를 사용하며, CRA에서 사용되는 Webpack보다 훨씬 빠릅니다. Vite의 속도는 Go 언어로 작성되어 빠른 멀티스레드 언어로 기계 코드로 컴파일되기 때문에 생겨난 것입니다. 이에 반해 Webpack은 JavaScript로 작성되었고 해석되며 단일 스레드로 작동되어 더 느립니다.

보다 유연한 설정

많은 사람들은 CRA를 선택한 이유가 구성이 필요하지 않기 때문입니다. CRA의 주요 장점은 단일 명령으로 React 애플리케이션을 실행할 수 있는 능력입니다. 그러나 이는 유연성의 부족이라는 대가를 지닙니다. 큰 프로젝트에서는 분명히 CRA에 새로운 기능을 추가해야 할 필요성을 느낄 것입니다.

CRA가 기능을 지원하지 않을 때, 그 한계를 해결하기 위해 다양한 조치들이 필요합니다. 예를 들어 Webpack의 구성 파일을 복원하려면 CRA 자체 대신 CRACO를 설치해야 하며, 이로 인해 CRA 버전 4를 사용하는 것으로 제한됩니다.

반면 Vite는 rollup.js를 고려하여 개발된 플러그인 지원을 가지고 있습니다. 이는 빠르게 Rollup 플러그인을 작성할 수 있는 인기 있는 솔루션으로, 누락된 기능을 추가할 수 있도록 도와줍니다. Rollup은 훨씬 더 다양한 플러그인 생태계를 가지고 있어 필요에 맞는 환경을 생성할 수 있습니다.

프레임워크 지원

Vite는 React, Vue, Svelte와 같은 다양한 프레임워크를 사용합니다. CRA는 능력을 React에만 한정합니다. 다른 프레임워크에서 애플리케이션을 개발할 때마다 처음부터 새로운 도구를 학습해야 할 필요가 있습니다. Vite는 Vue의 창시자들이 만들었음에도 불구하고 React, Vue 및 SolidJS, Svelte 또는 Lit과 같은 덜 인기 있는 프레임워크를 구성할 수 있게 해줍니다. 모든 프로젝트에서 Vite를 사용함으로써 많은 학습 시간을 절약하고 새로운 개발자들이 쉽게 프로젝트에 참여할 수 있도록 합니다.

개발

이전에는 Snowpack라는 솔루션을 사용했으나, 불행히도 해당 프로젝트는 더 이상 유지되지 않아 계속해서 도구를 바꾸는 악순환에 빠지지 않도록 잘 개발된 대안을 찾기 시작했습니다. 그와 반대로 Vite는 상당히 안정적이며 포괄적인 생태계를 가지고 있습니다. npm에서 평균 주당 2.5백만 다운로드를 기록하고 있으며, 업데이트는 평균 한 달에 한 번씩 출시되며 커뮤니티는 계속해서 수정 작업을 진행하고 있습니다.

핵심기능

가장 중요한 이득은 응용 프로그램 개발 중의 속도입니다. 브라우저에서 응용 프로그램이 새로 고침되기까지 몇 초를 기다려야만 하는 경우 집중력을 잃고 주의가 흐트러질 수 있습니다. 이는 하루에 수백 번 이상 발생할 수 있습니다. Vite를 사용하면 이러한 문제를 겪지 않게 됩니다.

실제 사례

더 작은 프로젝트에서 CRA를 Vite로 교체한 결과, 애플리케이션 빌드 시간이 거의 절반으로 줄었습니다. 28.4초에서 16.1초로 개선되었습니다. 이 시간 절약은 Github Actions와 같은 자동화에서 가장 두드러집니다. 로컬 서버도 훨씬 빨리 시작됩니다. CRA는 동일한 프로젝트를 4.5초에 시작하지만, Vite는 390ms에 작업을 수행합니다. 이는 상당한 시간을 절약해줍니다. 개발자가 프로젝트에서 작업하는 경우 차이가 눈에 띄지 않을 수 있지만, 더 큰 규모에서는 이미 절약이 크게 나타납니다.

처음 빌드 및 배포에서의 시간 절약은 좋은 점일 수 있지만, 더 좋은 것이 있습니다. 개발 중에는 변경 사항을 빠르게 반영하기 위해 각 변경 후 애플리케이션을 다시 로드하는 핫 리로드 기능을 자주 사용합니다. CRA에서는 저장 후 뷰가 업데이트되기까지 약 5초를 기다려야 했습니다. 그러나 Vite에서는 이것이 거의 즉시 발생하여 개발을 더 즐겁고 효율적으로 만들어주며, 애플리케이션을 빌드하기를 기다리는 동안 기다리는 시간으로 인한 주의산만을 방지합니다. 이는 작업의 품질을 완전히 변화시킵니다.

매번 약간의 시간을 절약한다고 해서 별로 중요하지 않아 보일 수 있지만, 여러 분을 걸리는 큰 애플리케이션을 생각해보면 몇 분이 걸릴 수도 있는데, 그럴 때 차이는 분명히 더 눈에 띄게 됩니다.

아래 테이블은 CRA 에서 Vite 로 전환한 몇 가지 프로젝트의 예시입니다:

요약

Create React App는 React로 간단한 첫 번째 앱을 구축하는 데 적합합니다. 그러나 빠르게 제한 사항을 인식하게 되며, 앱을 생성할 때 더 유연한 도구를 선택하는 것이 의미가 있습니다.

만약 리액트 말고도 다양한 프레임워크를 사용할경우 Vite는 더욱 좋은 선택이 될것같습니다.

속도와 구성의 간편함으로 인해 Vite로 전환하는 데 투자한 시간은 빠르게 보답받습니다. 거대한 기능을 가지고 있음에도 불구하고, 이 도구는 사용하기 쉬우며 개발자들을 제한하지 않습니다. 무엇보다도 Vite의 사용은 시간을 절약해주며 어떤 JS 프로젝트에도 유연하게 적용할 수 있습니다.

[React] HOC (고차 컴포넌트, Higher-Order Component)

code walker — Fri, 18 Aug 2023 12:49:32 +0900

HOC 란?

리액트의 HOC(고차 컴포넌트, Higher-Order Component)는 컴포넌트 간의 로직을 재사용하기 위한 패턴입니다.

HOC는 함수이며, 인자로 컴포넌트를 받아들이고, 새로운 컴포넌트를 반환합니다. 이렇게 반환된 컴포넌트는 원본 컴포넌트의 기능을 감싸거나 수정하는 데 사용됩니다.

우선 리액트 공식문서에서 설명이 잘 나와있어서 아래의 이미지를 스크랩 해왔습니다.

HOC 활용 및 활용 이유

함수 반환: HOC는 함수입니다. 이 함수는 인자로 컴포넌트를 받아들이고, 새로운 컴포넌트를 반환합니다.

로직 분리: HOC를 사용하여 여러 컴포넌트에서 중복되는 로직을 분리하여 재사용할 수 있습니다. 예를 들어, 인증, 권한 관리, 로깅 등과 같은 기능을 여러 컴포넌트에서 공통으로 사용하려고 할 때 HOC를 사용할 수 있습니다.

컴포넌트 감싸기: HOC는 원본 컴포넌트를 감싸는 형태로 동작합니다. 이로 인해 기존 컴포넌트의 기능을 확장하거나 수정할 수 있습니다. 인자 전달: HOC는 인자를 전달하여 컴포넌트에 추가 데이터나 기능을 제공할 수 있습니다. 이를 통해 컴포넌트 간의 상호작용을 구현할 수 있습니다. 명명 규칙: 보통 HOC는 이름 앞에 "with"를 붙여 명명됩니다. 예를 들어, withDoSomething 와 같은 이름을 가질 수 있습니다.

컴포지션: 여러 HOC를 함께 사용하여 여러 개의 기능을 한 컴포넌트에 적용할 수 있습니다. 이러한 컴포지션은 컴포넌트 간의 강력한 로직 재사용을 가능케 합니다.

HOC를 사용하면 여러 컴포넌트 간에 공통으로 사용되는 코드를 중앙에서 관리할 수 있어 유지보수성이 향상되고, 코드 중복을 줄일 수 있습니다.

또한 HOC는 상속을 사용하지 않고도 컴포넌트의 기능을 확장하거나 수정할 수 있어 유연한 코드를 작성하는 데 도움이 됩니다. 리액트 훅의 도입으로 함수형 컴포넌트에서도 상태 관리와 사이드 이펙트 처리가 용이해져서 클래스 컴포넌트를 대체하는 경우가 많아졌지만, HOC는 여전히 유용한 상황이 있을 수 있습니다.

규모가 큰 애플리케이션에서 state와 setState 를 호출하는 동일한 패턴이 반복적으로 발생한다고 가정해봅시다. 그렇게 된다면 이 로직을 한 곳에서 정의하고 많은 컴포넌트에서 로직을 공유할 수 있게 하는 추상화가 필요하게 됩니다.

이러한 경우에 고차 컴포넌트를 사용하면 좋습니다. from React 공식문서

예시

HOC 패턴의 이해를 돕기 위해 직접 코드로 간단한 예시를 만들어봤습니다.

HOC 패턴은 클래스형 컴포넌트와 함수형 컴포넌트 둘다 가능하지만 , hooks의 사용을 편하게 하기위해 함수형으로 예제로 준비해봤습니다.

아래의 두가지 코드는 간단히 num state를 increseNum 이란 함수를 통해서 +1 씩 증가시키는 간단한 예제입니다.

제목이 First, Second 라는 것만 다르고 , 로직과 UI는 똑같습니다.

Before applying HOC

//Frist.tsx


import { useState } from "react"

export default function Frist() {

  const [num, setNum] = useState<number>(0);

  const increaseNum = () => {
    setNum(prev => prev + 1)
  }

  return (
    <div>
      <h1>First / {num}</h1>
      <button onClick={increaseNum}>Increase First Number</button>
    </div>
  )
}

// Second.tsx

import { useState } from "react";

export default function Second() {

  const [num, setNum] = useState<number>(0);

  const increaseNum = () => {
    setNum(prev => prev + 1)
  }

  return (
    <div>
      <h1>SECOND / {num}</h1>
      <button onClick={increaseNum}>Increase Second Number</button>
    </div>
  )
}

이렇게 비슷한 로직을 추가로 컴포넌트를 통해 구현을 해야할때, 지금은 두개라서 useState와 setState의 로직을 하나씩 작성해줬지만 만약에 10개,100개가 넘어가면 중복성이 너무 심할것같다는 생각이 들건데요.

여기서 인자로 컴포넌트를 받아들이고, 새로운 컴포넌트를 반환해서, 컴포넌트 재사용성이 높은 HOC 패턴을 이용해 중복로직을

줄여보겠습니다.

아래와 같이 HOC.tsx 파일을 하나 만들고 위의 num 을 증가시키는 로직 (num state 와 increase 함수)를 작성해줍니다.

여기서 중요한것은 HigherOrderComponent의 인자로는 나중에 Wrapping할 컴포넌트를 전달 해준다는 것 입니다.

// HOC.tsx

import React, { useState } from 'react'

interface CounterProps {
  num: number;
  increaseNum: () => void;
}

const WithHihgerOrderComponent = (Counter: React.ComponentType<CounterProps>) => {
  const HigherOrderComInner = () => {
    const [num, setNum] = useState(0);
    const increaseNum = () => {
      setNum(prev => prev + 1)
    }
    return (
      <Counter num={num} increaseNum={increaseNum}/>
    )
  }
  return HigherOrderComInner;
}

export default WithHihgerOrderComponent;

이제 Frist , Second 컴포넌트에서 HigherOrderComponent로 감싸주기만 한다면 기능은 똑같이 작동합니다.

그전에 , 기존에 First, Second 컴포넌트에서 중복되었는 useState 와 increaseNum의 함수를 HOC에서 컨트롤 하고 있으니

먼저 지워준뒤 , HOC에서 전달받은 props로 num의 state 와 increaseNum 으로 기능 구현을 해줍니다.

After applying HOC

// After wrapping HOC First.tsx

import WithHihgerOrderComponent from "./HOC";

interface CounterProps {
  num: number;
  increaseNum: () => void;
}

function First({num,increaseNum}:CounterProps) {
  return (
    <div>
      <h1>SECOND / {num}</h1>
      <button onClick={increaseNum}>Increase Second Number</button>
    </div>
  )
}

export default WithHihgerOrderComponent(First);

// After wrapping HOC Second.tsx

import WithHihgerOrderComponent from "./HOC";

interface CounterProps {
  num: number;
  increaseNum: () => void;
}

function Second({num,increaseNum}:CounterProps) {
  return (
    <div>
      <h1>SECOND / {num}</h1>
      <button onClick={increaseNum}>Increase Second Number</button>
    </div>
  )
}

export default WithHihgerOrderComponent(Second);

예시2

이번 예시는 jsonplaceholder dummy api 를 이용해 user 리스트와 todo 리스트를 갖고오는 컴포넌트를 하나씩 생성해서 데이터를 불러와보겠습니다.

이번 예제 역시 불러오는 api 엔드포인트만 다르고 모든 로직 및 UI 는 같습니다.

Before applying HOC

// User.tsx

import { useEffect, useState } from "react"

interface UserItem {
  id:number;
  name:string;
  username:string;
  email:string;
}

export default function User() {

  const [user, setUser] = useState<UserItem[]>([]);

  useEffect(() => {
    const getData = async () => {
      const data = await fetch('https://jsonplaceholder.typicode.com/users');
      const json = await data.json();
      setUser(json);

    };
    getData();
  }, []);

  console.log(user);
  
  return (
    <div>
      <h1>Users</h1>
      <ul>
        {user?.slice(0, 10).map((user) => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  )
}

// Todo.tsx

import { useEffect, useState } from "react"

interface TodoItem {
  userId: number;
  id: number;
  title: string;
  completed: boolean;
}

export default function Todo() {

  const [todo, setTodo] = useState<TodoItem[]>([]);

  useEffect(() => {
    const getData = async () => {
      const data = await fetch('https://jsonplaceholder.typicode.com/todos');
      const json = await data.json();
      setTodo(json);

    };
    getData();
  }, [])
  
  return (
    <div>
      <h1>To do</h1>
      <ul>
        {todo?.slice(0, 10).map((todo) => (
          <li key={todo.id}>{todo.title}</li>
        ))}
      </ul>
    </div>
  )
}

위와 코드는 api 엔드포인트만 다르죠? User 컴포넌트는 users , Todo 컴포넌트는 todos 를 통해 각 데이터를 호출 하고있습니다.

useEffect를 통해 데이터를 빈 state에 setState를 통해 데이터를 채워주는 로직이 똑같습니다.

위의 코드를 HOC 패턴을 이용해 코드의 중복성을 줄이고 재사용성을 높여 보겠습니다.

위의 예제와 완전 똑같지만 , API 의 endpoint를 동적으로 받아와야하기 때문에 인자에 endpoint를 하나 더 생성 해줬습니다.

HOC 컴포넌트의 list의 api 호출한 결과값을 데이터에 담고 props로 전달해줍니다.

// HOC.tsx

import React, { useEffect, useState } from 'react';

export interface UserItem {
  id: number;
  name: string;
}

export interface TodoItem {
  id:number;
  title:string;
}

export interface ListProps<T> {
  list: T[];
}

const WithHihgerOrderComponent = <T extends UserItem | TodoItem>(
  DataList: React.ComponentType<ListProps<T>>,
  endpoint: string
) => {
  const HigherOrderComponentInner = () => {
    const [list, setList] = useState<T[]>([]);

    useEffect(() => {
      const getData = async () => {
        const data = await fetch(`https://jsonplaceholder.typicode.com/${endpoint}`);
        const json = await data.json();
        setList(json);
      };
      getData();
    }, []);

    return <DataList list={list} />;
  };
  return HigherOrderComponentInner;
};

export default WithHihgerOrderComponent;

After applying HOC

// Todo.tsx

import WithHihgerOrderComponent, { ListProps, TodoItem } from "./HOC"

function Todo({list}:ListProps<TodoItem>) {
  return (
    <div>
      <h1>To do</h1>
      <ul>
        {list.slice(0, 10).map((todo) => (
          <li key={todo.id}>{todo.title}</li>
        ))}
      </ul>
    </div>
  )
}

export default WithHihgerOrderComponent(Todo,'todos')

// User.tsx

import WithHihgerOrderComponent, { ListProps, UserItem } from "./HOC"

function User({ list }:ListProps<UserItem>) {
  return (
    <div>
      <h1>User</h1>
      <ul>
        {list.slice(0, 10).map((user) => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  )
}

export default WithHihgerOrderComponent(User, 'users')

HOC를 적용하고나서의 화면

같은 로직과 같은 UI가 중복된점이 있으면 HOC를통해 보다 나은 (유지보수성) 을 고려하면서 코드를 짤 수 있습니다.

HigherOrderComponent의 두번째 인자로 API endpoint를 넣어서 하나의 컴포넌트에서 동적으로 데이터를 받아옴으로서 재사용성이 높은, 중복을 줄일 수 있는 코드를 작성할 수 있습니다.

HOC 패턴을 사용하면 코드의 재사용성, 모듈화, 분리된 관심사, 컴포지션 등 여러 가지 장점을 얻을 수 있습니다. 이로 인해 코드의 유지보수성과 가독성이 향상되며, 확장 가능한 애플리케이션을 개발할 수 있습니다.

잘못된 부분이 있으면 언제든지 알려주시길 바랍니다. :)

[React]When to use UseMemo and useCallback (feat:memo) / useCallback 편

code walker — Wed, 9 Aug 2023 17:57:24 +0900

리액트로 프론트 개발을 하다면 useMemo , useCallback 과 같은 컴포넌트 렌더링 최적화 훅을 한번쯤은 들어봤을텐데요.

저는 솔직히 지금까지 제일 헷갈리는것 같습니다. 왜냐하면 렌더링 최적화 훅이라고 해도 그냥 막 사용하면 오히려 최적화가 아니라

성능에 안좋을 수 있어서, 상황에 맞게 잘 써야합니다.

메모이제이션

우선 useCallback 과 useMemo를 사용하기 위해선 "메모제이션" 이란 단어를 필수로 짚고 넘어가야합니다.

메모제이션(memoziaiton)은 expensive 한 함수 호출 결과를 캐싱하고 같은 입력이 재발생 될때 캐싱된 결과를 그대로 반환하는

프로그래밍 기술 입니다.

리액트 함수형 컴포넌트에서 동일한 입력으로 여러번 호출 되는 상황이 꽤 많습니다.

이때 리액트에서 메모이제이션을 사용할때 useMemo , useCallback 훅을 사용해서 렌더링 최적화 및 성능 상향을 시킬 수 있습니다.

useMemo 와 useCallback을 배우기전에 알아야 하는것

1. 우선 리액트 함수형 컴포넌트는 단지 jsx 를 반환하는 함수 입니다.

2. 컴포넌트가 렌더링 된다는것은 컴포넌트(함수)를 호출이 되서 실행이 되고 , 자바스크립트의 함수는 실행 될때마다 내부에 선언되어있던 변수가 매번 다시 선언 되어 사용됩니다.

3. 함수형 컴포넌트는 자신의 state가 변경되고, 자식컴포넌트 경우 부모컴포넌트의 state가 변경 되어도 리렌더링(재호출)이 된다.

useMemo :메모이제이션 된 값을 반환합니다.

useCallback :메모이제이션 된 함수를 반환합니다.

또한 자바스크립트의 기초가 있다면 참조타입의 함수나 객체 배열은 아래와 같이 작동합니다.

let dog1 = func(){console.log('14/10')}; // has a unique object reference
let dog2 = func(){console.log('14/10')}; // has a unique object reference

dog1 === dog2; // false

let arr = [1,2,3]
let arr2 = [1,2,3]

arr === arr2 // false;

const obj = {name:'kwangmin'}
const obj2 = {name:'kwangmin'}

obj === obj2 // false;

헷갈리지 말아야할게 변수에 할당된 객체가 직접 다른 변수에 할당된 경우 참조가 일치할 것입니다.

let dog1 = func(){console.log('14/10')}; // has a unique object reference
let dog2 = dog1;  // assign the unique object reference of dog1 to a variable named dog2

// dog1 and dog2 point to same object reference
dog1 === dog2; // true

let arr = [1,2,3,4];
let arr2 = arr;

arr === arr2 // true

const obj = {name:'kwangmin'};
const obj2 = obj;

obj === obj2 // true

UseCallback

그럼 useCallback 언제 어떻게 사용하는지 알아보겠습니다.

ParentComponent라는 컴포넌트를 생성해 보겠습니다.

이 컴포넌트에는 age와 salary라는 상태(state) 그리고 다음과 같은 함수들이 있습니다
1. incrementAge(): "나이 증가" 버튼을 클릭하면 나이를 1 증가시킵니다.
2. incrementSalary(): "급여 증가" 버튼을 클릭하면 급여를 1000 Rs 증가시킵니다.

ParentComponent는 다음과 같이 3개의 자식 컴포넌트를 가지고 있습니다.
1. <Title>: 페이지 제목을 렌더링합니다.
2. <Count>: 페이지에 나이나 급여를 표시합니다.
3. <Button>: 나이와 급여를 증가시키기 위한 버튼입니다. 이 세가지 컴포넌트 모두 컴포넌트가 재렌더링될 때마다 로그 문장을 추가하여 결과를 확인할 수 있도록 합니다.

Code Snippet

// App.tsx
import ParentComponent from "./components/ParentComponet";

export default function App() {
  return (
    <ParentComponent/>
  )
}

// ParentComponet.tsx

import React, { useState } from 'react';
import Button from './Button';
import Title from './title';
import Count from './Count';
function ParentComponent() {
  const [age, setAge] = useState(25);
  const [salary, setSalary] = useState(25000)
  const incrementAge = () => {
    setAge((prev => prev +1));
  }
  const incrementSalary = () => {
    setSalary(prev => prev + 10000);
  }
  return (
    <div>
      <Title />
      <Count text="age" count={age} />
      <Button handleClick={incrementAge}>Increment my age</Button>
      <Count text="salary" count={salary} />
      <Button handleClick={incrementSalary}>Increment my salary</Button>
    </div>
  );
}
export default ParentComponent;

// Button.tsx
import React from 'react';

function Button(props:any) {
  console.log(`Button clicked ${props.children}`);
  return (
    <div>
      <button onClick={props.handleClick}> {props.children} </button>
    </div>
  );
}
export default Button;

// Count.tsx
import React from 'react';

function Count(props:any) {
  console.log("Count rendering");
  return (
    <div>
      {props.text} is {props.count}
    </div>
  );
}
export default Count;

// Title.tsx

export default function Title() {
console.log("Title is rendering.")
  return (
    <div>
      <h2>useCallBack hook</h2>
    </div>
  )
}

incrementAge 버튼을 클릭하면 나이가 25에서 26으로 증가합니다. 그러나 콘솔에서 확인해보면 모든 컴포넌트가 다시 호출되었습니다나이가 성공적으로 증가되었음을 볼 수 있지만, 다른 모든 컴포넌트도 매번 재렌더링되었고, 그렇게 되면 안되겠죠?
App에서 변경된 것은 나이 상태 뿐입니다. 그럼에도 불구하고 모든 리액트 컴포넌트가 변경 여부와 관계없이 재렌더링됩니다.

예제에서 나이를 증가시킬 때는 두 가지만 다시 렌더링되어야 합니다. 나이와 관련된 Count 컴포넌트. 나이를 증가시키는 Button 컴포넌트. 다른 세 가지 로그 문장은 다시 렌더링될 필요가 없습니다. 급여 역시 마찬가지입니다.

급여를 증가시키면 제목과 나이 컴포넌트가 다시 렌더링되지 않아야 합니다. 그렇다면 어떻게 이를 최적화할 수 있을까요?

그 답은 React.memo() 입니다.

React.memo란?

React.memo는 함수형 컴포넌트의 부모 컴포넌트로부터 전달받은 props나 상태state 변경되지 않는 한 해당 컴포넌트의 재렌더링을 방지하는 고차 컴포넌트(HOC)입니다. React.memo()는 훅과 아무 관련이 없다는 것을 염두에 두시기 바랍니다. 이 기능은 리액트 버전 16.6부터 제공되었으며, 클래스 컴포넌트에서는 이미 PureComponent 또는 shouldComponentUpdate를 사용하여 재렌더링을 제어할 수 있었습니다.

아래와 같이 예제에서 React.memo()를 활용해 보겠습니다.

memo로 래핑을 해주세요.

export default React.memo(Button); 
export default React.memo(Count); //Count.js
export default React.memo(Title); //Title.js

이제 해당 컴포넌트는 상태(state)나 프롭스(props)에 변경이 있을 때만 재렌더링됩니다.

이게 잘 작동하는지 테스트해보죠. 그러나 여전히 안됩니다.

브라우저에서 페이지를 로드하면 처음에는 5개의 로그가 모두 나타납니다.

이제 incrementAge() 를 클릭한 후, 로그가 적어진 것을 볼 수 있습니다. 그럼에도 불구하고 아직 완벽하지 않습니다. 나이를 증가시키면 급여 증가 버튼이 여전히 재렌더링되고, 급여를 증가시키면 나이 증가 버튼이 재렌더링됩니다.
이런 일이 일어나는 이유를 알아보겠습니다.

Title 컴포넌트는 자체 state나 props가 없으므로 리렌더링되지 않습니다. Count는 나이를 props로 받고, 버튼은 incrementAge()를 props로 받으며 이것은 나이에 의존적입니다. 그래서 둘 다 재렌더링됩니다. 그런데 우리가 볼 수 있는 것은 incrementSalary 버튼도 재렌더링됩니다. 왜일까요?

급여에 대한 count 컴포넌트는 재렌더링되지 않습니다. 이는 부모 컴포넌트가 재렌더링될 때마다 새로운 incrementSalary 함수가 생성되기 때문입니다. 함수를 다룰 때는 항상 참조 동등성을 고려해야 합니다. 두 함수가 완전히 동일한 동작을 하더라도 서로 같다는 것을 의미하지 않습니다. 그래서 리렌더링 전의 함수와 리렌더링 후의 함수는 다릅니다. 그리고 함수인 handleClick이 props이기 때문에, React.memo는 프롭스가 변경되었다고 판단하고 재렌더링을 막지 않습니다. 그래서 3개의 로그가 남게 됩니다.

따라서 이제 React에게 매번 incrementSalary 함수를 생성할 필요가 없다는 것을 알려야 합니다. 그 답은 useCallback 훅입니다. useCallback 훅은 incrementSalary 함수를 캐시하고, 급여가 증가되지 않는 경우 해당 함수를 반환합니다. 급여가 변경될 경우에만 새로운 함수가 반환됩니다.

  const incrementAge = useCallback(() => {
    setAge(prev => prev + 1);
  }, [age]);

  const incrementSalary = useCallback(() => {
    setSalary(prev => prev + 10000);
  }, [salary]);

만약 자식 컴포넌트가 React.memo() 같은 것으로 최적화 되어 있고 그 자식 컴포넌트에게 callback 함수를 props로 넘길 때, 상위 컴포넌트에서 useCallback 으로 함수를 선언하는 것이 유용하다라는 의미이다. 함수가 매번 재선언되면 자식 컴포넌트는 넘겨 받은 함수가 달라졌다고 인식하기 때문이다. React.memo()로 함수형 컴포넌트 자체를 감싸면 넘겨 받는 props가 변경되지 않았을 때는 상위 컴포넌트가 메모리제이션된 함수형 컴포넌트(이전에 렌더링된 결과)를 사용하게 된다. 함수는 오로지 자기 자신만이 동일하기 때문에 상위 컴포넌트에서 callback 함수를 (같은 함수이더라도) 재선언한다면 props로 callback 함수를 넘겨 받는 하위 컴포넌트 입장에서는 props가 변경 되었다고 인식한다.

When should you not use the useCallback hook

useCallback 훅을 모든 참조 동등성 문제를 해결하기 위해 사용해서는 안 됩니다. 매번 재선언을 피하는 좋은 해결책처럼 보일 수 있지만, 여기서 주의할 점은 메모이제이션이 일부 데이터를 메모리에 저장하는 기술임을 염두에 두어야 합니다. 애플리케이션의 모든 부분을 메모이제이션하는 것은 더 많은 메모리 리소스를 사용하며, 이로 인해 애플리케이션의 성능에 부정적인 영향을 미칠 수 있습니다.

Reference

https://www.memberstack.com/blog/using-usecallback

Using useCallback Hook in React — A Developer's Guide | Memberstack Blog

www.memberstack.com

https://kentcdodds.com/blog/usememo-and-usecallback

When to useMemo and useCallback

Stay up to date Subscribe to the newsletter to stay up to date with articles, courses and much more! Learn more Stay up to date Subscribe to the newsletter to stay up to date with articles, courses and much more! Learn more All rights reserved © Kent C. D

kentcdodds.com