1. React의 기본 Hook과 HOC를 직접 구현하며 내부 동작 원리 이해하기
2. 직접 구현한 Hook을 활용해서 기존 코드 리팩토링해보기

과제 회고

이번 주는 useCallback, useMemo, useRef, useDeepMemo 같은 React 기본 Hook을 직접 구현해보고, memo, deepMemo 같은 HOC도 직접 만들어보며 동작 원리를 이해했다.

memo - HOC 직접 구현하기

어려웠던 점

memo는 컴포넌트를 인자로 받아 props가 바뀌지 않으면 리렌더링을 생략하는 방식으로 동작한다. 그래서 처음에는 함수 컴포너트의 결과를 클로저 내부에 저장해두고, props가 이전과 동일하다면 저장된 결과를 반환하도록 구현했다. 하지만 여러 곳에서 memo를 사용했을 때, 클로저에 저장된 값들이 덮어써지면서 props가 변경되지 않았음에도 불구하고 컴포넌트가 다시 렌더링되는 문제가 발생했다.

해결 과정

클로저 대신 userRef를 사용해, memo가 적용된 각 컴포넌트마다 별도로 결과를 저장하도록 변경했다. 이렇게 저장 범위를 분리하니 문제 없이 동작했다.

알게 된 것

클로저의 저장 범위(scope)를 명확히 설정하지 않으면 예상치 못한 리렌더링 문제가 발생할 수 있다는 걸 경험했다.

Context API에서의 렌더링 최적화

직접 만든 Hook을 적용하며 기존 코드를 리팩토링했고, Context를 사용할 때 불필요한 렌더링을 최소화하는 구조를 고민했다.

어려웠던 부분

우선 AppContext에 같이 있던 theme(다크모드 theme 설정), notification(로그인 알람 토스트), auth(로그인)를 각각의 context로 분리하였다. 그리고 각각의 context 상태가 변경 될 때, 불필요한 리렌더링이 발생하지 않도록 구조를 나누는 데 집중하였다. 예를 들어, 사용자가 로그인하면 알림 토스트가 나타나도록 구현되어 있었기 때문에 AuthProvider에서 NotificationContext를 참조해야 했다. 하지만 Context API는 context value가 변경되면 해당 값을 구독하는 모든 컴포넌트가 리렌더링된다는 특성이 있기 때문에, 헤더에 있는 로그인 버튼으로 로그인했을 때 알림 토스트가 뜨고, 그 알림을 닫았을 때 auth를 구독 중인 Header 컴포넌트가 불필요하게 리렌더링되지 않도록 구조를 어떻게 분리할지 고민하였다.

해결 과정

AuthProvider 안에서 직접 NotificationContext를 구독하는 대신, addNotification만 prop으로 전달하고 AuthProvider 자체를 memo()로 감쌌다.

...

<NotificationProvider>
    <AuthWithNotification>{children}</AuthWithNotification>
</NotificationProvider>

...

function AuthWithNotification({ children }: AuthWithNotificationProps) {
  const { addNotification } = useNotification("AuthWithNotification");
  return (
    <AuthProvider addNotification={addNotification}>{children}</AuthProvider>
  );
}

이렇게 하면 notification과 관련된 상태가 변경돼도 AuthProvider는 리렌더링되지 않는다. 또한, notification과 AuthProvider의 의존관계를 prop으로 명시적으로 표현할 수 있다.

알게 된 것

멘토의 코드를 참고하면서 AuthProvider 안에서 useNotification을 직접 사용하되, useCallback과 useMemo를 활용해 authContextValue의 참조를 고정시키는 방식이 더 구조적으로 깔끔할 수 있겠다는 생각이 들었다.

export const UserProvider: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
...

const login = useCallback(
    (email: string) => {
      setUser({ id: 1, name: "홍길동", email });
      addNotification("성공적으로 로그인되었습니다", "success");
    },
    [addNotification],
  );

  const logout = useCallback(() => {
    setUser(null);
    addNotification("로그아웃되었습니다", "info");
  }, [addNotification]);

  const userContextValue = useMemo(
    () => ({ user, login, logout }),
    [user, login, logout],
  );

  ...
}

추가적으로 멘토의 코드 리뷰를 통해 추천받은 방식 중 하나가, notification과 AuthProvider의 의존관계를 더 명시적으로 쓰도록 강제하고 싶다면 의존관계를 children 콜백 패턴으로 표현하는 것이다.

export const AppProvider = ({ children }: AppProviderProps) => {
  return (
    <ThemeProvider>
      <NotificationProvider>
        {(notificationAPI) => (
          <AuthProvider notificationAPI={notificationAPI}>
            {children}
          </AuthProvider>
        )}
      </NotificationProvider>
    </ThemeProvider>
  );
};

이 방식은 AuthProvider가 notification API를 명시적으로 전달받게 되므로, 구조적으로 NotificationProvider가 상위에 존재해야 한다는 제약을 코드 레벨에서 자연스럽게 강제할 수 있다. 의존관계를 좀 더 겉으로 드러내고 명확히 표현할 수 있다는 점에서 인상 깊었다. 기존의 useNotificationContext 방식도 간결하고 편리하지만, 의존성이 암묵적으로 감춰지는 단점이 있다는 걸 생각해보지 못했다. 설계적인 안정성과 구조적인 명확함이 중요한 상황이라면, 이런 형태의 의존성 전달도 충분히 고려해볼 만하다는 생각이 들었다.

마무리

이번 과제를 진행하면서 학습메이트에게 Redix UI의 undefined safe한 context 생성 함수를 추천받았다. 이 코드 패턴을 참고하면 createContext를 좀 더 간결하게 사용할 수 있고, Provider와 useContext hook을 한 번에 구성할 수 있어서 적용해보면 좋겠다는 생각이 들었다. 역시 같이 공부하면 참고할 수 있는 자료나 시야가 훨씬 넓어지는 느낌이다.

Generator 생성하기

nx g generator svg-icon-codegen --project=plugin

• libs/plugin/src/generators 경로에 svg-icon-codegen 이름을 가진 generator를 생성합니다.
• --dry-run 옵션을 사용하면 CLI에서 미리 실행 결과를 볼 수 있습니다. (실제로 변경이 일어나지 않음)

Generator 실행하기

nx generate svg-icon-codegen

• svg-icon-codegen이라는 generator를 실행합니다.
• svg-icon-codegen/generator.ts 코드가 실행됩니다.

Generator 코드 작성하기

// The initial generator function

import { Tree } from '@nrwl/devkit';

export default async function (tree: Tree, options: any) {
    ...
}

• schema.json에 properties를 정의하면 options의 property로 받아서 사용할 수 있습니다.
• @nrwl/devkit 패키지는 파일 수정, 파일 읽기 및 업데이트, AST(Abstract Syntax Tree) 작업을 위한 많은 유틸리티 기능을 제공합니다.

ex. project path 가져오기 'shared-ui-system'의 root path를 가져옵니다.

const projectRoot = readProjectConfiguration(tree, 'shared-ui-system').root;

ex. path 합치기 'shared-ui-system' project 하위 icons path에 CalendarPlusIcon path를 붙여서 새로운 path를 만듭니다.

// libs/shared/ui-system/src/lib/icons/CalendarPlusIcon

const path = joinPathFragments(projectRoot, `src/lib/icons/${options.name}Icon`);

ex. 파일 생성하기

generateFiles(tree: Tree, srcFolder: string, target: string, substitution) srcFolder에 있는 파일을 target 경로에 생성합니다.

generateFiles(tree, joinPathFragments(__dirname, './files/src'), `${iconRoot}/__generated__/`, { ...options, template: '' });

substitution에 정의한 key는 value로 replace 되어집니다. { template: '' } 로 설정하면 srcFolder에 index.ts__template__ 파일은 index.ts 파일로 생성됩니다.

ex. 파일 수정하기

const contents = tree.read(filePath).toString();
const newContents = `export * as ${options.name}Icon from './${options.name}Icon';`;

tree.write(filePath, contents + newContents);

팁

shema.json에서 properties 설정할 때 x-prompt를 설정하면 한결 친절?하게 generator를 실행시킬 수 있습니다 :)

ex. react native svg icon component 생성하기 <HomeSmileIcon.Fill />, <HomeSmileIcon.Line />

참고

Nx Docs generator Nx Docs local-generators

• Gzipped size: 33.81KB

Lodash 모듈 용량 최적화 방법

lodash가 번들을 크게 만드는 이유는 lodash가 CommonJS로 작성되어 있기 때문입니다. (CommonJS가 번들을 더 크게 만드는 이유 참고)

lodash tree shaking 관련 검색을 해보니 2가지 정도 방법이 있었습니다.

1. member style imports를 default style imports로 변경하기
2. lodash-es 사용하기

저는 이 중에서 member style imports를 default style imports로 변경하는 방법으로 작업을 진행하였습니다.

member style imports를 변경해야 하는 이유는 모든 lodash 함수가 포함된 lodash.js 파일을 통째로 가져오기 때문입니다. 실제로 측정한 lodash 번들을 살펴보면 왼쪽에 lodash.js가 통째로 들어있는 것을 확인할 수 있습니다.

member sytle imports

import { merge } from 'lodash'

default style imports

import merge from 'lodash/merge'

프로젝트에 있는 모든 lodash 코드를 직접 찾아서 바꿔줄 수도 있지만 Babel이나 SWC, Nex.js config 설정으로 간단하게 작업할 수 있습니다.

Babel 설정하기

babel-plugin-transform-imports plugin을 사용하면 기존 코드를 모두 수정하지 않고 default style imports로 변경할 수 있습니다.

SWC 설정하기

Babel이 아닌 SWC를 사용하고 있다면 webpack에 swc-plugin-transform-import plugin을 적용합니다.

Next.js 11 이상 버전에서는 default 설정으로 Babel 대신 SWC를 사용하고 있습니다. (SWC is 20x faster than Babel on a single thread and 70x faster on four cores.)

Next.js에서 Babel 설정(.babelrc 파일 생성)을 한다면 자동으로 JavaScript/TypeScript를 컴파일하기 위해 SWC를 사용하지 않고 Next.js 11에서 사용했던 것과 같은 방식으로 Babel을 사용하게 됩니다.(SWC disabled)

Next.js modularizeImports 기능 사용하기

Next.js에서 제공하는 실험적인 기능으로 Modularize Imports 설정을 지원합니다.

module.exports = {
  experimental: {
    modularizeImports: {
            lodash: {
        transform: 'lodash/{{member}}',
      },
    },
  },
}

• lodash member style imports를 default style imports로 변환해 줍니다.

module.exports = {
  experimental: {
    modularizeImports: {
      'my-library/?(((\\w*)?/?)*)': {
        transform: 'my-library/{{ matches.[1] }}/{{member}}',
      },
    },
  },
}

• lodash가 아닌 라이브러리에도 커스텀하게 설정이 가능합니다.

Lodash 최적화 결과

• Gzipped size: 11.94KB