High Order Component 를 아시나요?

😙 HighOrderComponent란?

고차 컴포넌트란 컴포넌트 로직을 재사용하기 위한 기술입니다.

리액트 문서의 정의에 따르면 고차 컴포넌트는

"컴포넌트를 가져와 새 컴포넌트를 반환하는 함수" 라고 해요

 

const EnhancedComponent = higherOrderComponent(WrappedComponent);

 

예제를 보면 다음과 같은데 구조만 보면 꽤나 익숙합니다.

React에서 제공하는 forwardRef , memo와 같은 함수들의 사용형태와 같은데

redux의 connect 함수도 생각이 나네요

 

---

😇 횡단 관심사(cross cutting concerns)

 

이러한 고차컴포넌트 패턴은 리액트에서 횡단관심사를 통하여 로직을 바라볼 수 있게 도와줍니다.

이전에는 mixin을 사용하여 구현하였으나 mixin이 가지는 문제가 있어

고차컴포넌트 패턴을 권장하는 형태로 바뀌었다고 해요

 

서로 다른 일을 수행하는 객체,로직들 사이에서 공통적으로 적용되는 관심사들을

횡단하는 것을 통하여 코드를 깨끗하게 분리해낼 수 있으며 + 재사용할 수 있어집니다.

 

따라서 고차 컴포넌트 패턴을 적용하면 좋을 상황도 쉽게 추론할 수 있습니다.

많은 컴포넌트에서 공통적으로 사용되는 로직을 분리하고 싶은 경우 유용하겠죠?

 

---

 

😌 나의 부끄러운 착각

<Suspense fallback={<div>loading</div>}>
  <Fetcher/>
<Suspense/>

저는 이 코드에서 서스펜스와 같이 자식 컴포넌트를 감싸주는 부모 컴포넌트를

고차컴포넌트라고 부르는 줄 알았는데 아니더라구욤..

 

위와 같은 형태의 컴포넌트들은 컨테이너 / 래퍼 컴포넌트라고 부르는 듯 합니다.

 

---

🥰 직접 구현해보기

 

프론트엔드에서 이러한 고차컴포넌트 패턴을 잘 활용할 수 있는 대표적인 예시는

인증 / 인가 여부에 따라 접근할 수 있는 컴포넌트, 화면을 다르게 설정하는 것을 떠올릴 수 있습니다.

 

이러한 예시를 직접 간단하게 구현해봅시다.

실습환경은 next.js pages router/ jotai이지만 두 라이브러리, 프레임워크에 대한 지식이 없어도

상관없을만큼 간단한 예시를 준비했으니 이런식으로 하면 되겠구나 감만 잡으시면 되겠습니다.

 

import { atom } from 'jotai';

type CertificationType = {
  isLogin: boolean;
  accessToken: string | null;
};

export const certificationAtom = atom<CertificationType>({
  isLogin: false,
  accessToken: null,
});

 

먼저 인증을 구현하기 위해 로그인을 했는지 구분하는 전역 상태를 만들어주겠습니다.

여러가지 방법으로 구현할 수 있지만 간단하게 전역상태를 쓰기 위해 jotai를 써주겠습니다.

jotai는 provider를 감싸주지 않아도 사용할 수 있습니다. 

 

import { certificationAtom } from '@/src/store/certification';
import { useAtom } from 'jotai';
import React from 'react';

interface LoginPageProps {}

const LoginPage = ({}: LoginPageProps) => {
  const [state, setState] = useAtom(certificationAtom);
  return (
    <div>
      <button
        onClick={() => {
          setState((s) => ({
            isLogin: !s.isLogin,
            accessToken: s.accessToken ? null : 'dsalkfmdkfdkl',
          }));
        }}
      >
        로그인하기
      </button>
    </div>
  );
};

export default LoginPage;

 

useAtom안에 만들어둔 아톰을 넣어두면 간단하게 상태를 useState처럼 사용할 수 있습니다.

로그인 페이지 컴포넌트에는 로그인 상태를 반전시키는 간단한 버튼을 만들어주겠습니다.

 

로그인이 필요한 경우에는 로그인 페이지 컴포넌트가 렌더링되며

버튼을 누르는것을 통해 로그인을 할 수 있게 하는 코드입니다.

 

import LoginPage from '@/src/routes/login/login.page';
import { certificationAtom } from '@/src/store/certification';
import { useAtom } from 'jotai';
import React from 'react';

export const withCertified = <P extends object>(
  Component: React.FunctionComponent<P>,
) => {
  const WrappingComponent = (prop: P) => {
    const [certification, setCertification] = useAtom(certificationAtom);
    if (certification.isLogin) {
      return <Component {...prop} />;
    }
    return <LoginPage />;
  };
  const displayName = Component.displayName || Component.name || 'Component';
  WrappingComponent.displayName = `Certified(${displayName})`;
  return WrappingComponent;
};

 

이제 본격적으로 고차컴포넌트를 구현해봅시다.

고차컴포넌트 패턴은 그 특성상 상용구가 조금 필요하다는 점을 기억해야하는데요

 

개인적으로는 어쩔 수 없는것이 아닌가 싶습니다.

컴포넌트를 반환하는 함수를 만들어야하는 것이니까요

 

고차컴포넌트는 훅과 비슷하게 네이밍 규칙이 존재합니다.

훅과 달리 반드시 지켜야만 하는 것은 아니지만 개발자들 사이에서 통상적으로 쓰이는 네이밍 규칙이니

기억해두시면 좋을 듯 합니다. 커스텀 고차컴포넌트의 네이밍은 with로 시작해야합니다.

 

고차컴포넌트는 컴포넌트를 인수로 받고 필요한 동작을 수행한 뒤 인수로 받은 컴포넌트를 반환하면 됩니다.

 

다만 필요한 부분이 있는데 바로 대부분의 컴포넌트는 props를 받는다는 것입니다.

그렇다보니 인수로 받은 컴포넌트가 받아야할 props를 적절히 추론시킬 수 있어야할 것입니다.

그것을 하기위해 제네릭을 통해 인수로 받은 컴포넌트가 가져야하는 props를 추론합니다.

 

displayName의 경우에는 필수적인 부분은 아니지만 해주면 좋으니까

(eslint의 불평을 잠재울수있고 / 리액트 디버거의 도움을 받기 쉬워집니다.)

 

export default withCertified(HighOrderConsumer);

 

이렇게 제작한 고차컴포넌트를 컴포넌트에 래핑해주는 작업을 통해 사용합니다.

---

 

🙃 highordercomponent vs wrapper

 

사실 위에서 고차컴포넌트로 구현한 작업은 wrapper를 만드는 것으로도 비슷하게 수행할 수 있습니다.

import LoginPage from '@/src/routes/login/login.page';
import { certificationAtom } from '@/src/store/certification';
import { useAtomValue } from 'jotai';

export const CertificationWrapper = ({
  children,
  fallback,
}: {
  children?: React.ReactNode;
  fallback?: React.ReactNode;
}) => {
  const certificate = useAtomValue(certificationAtom);
  if (certificate.isLogin) {
    return children;
  }
  return fallback ?? <LoginPage />;
};

이와 같이 적절한 값일때에만 children을 렌더하고 그렇지 않은 경우에는 login을 렌더하는 전략을 통해서 말이에요

 

그렇다면 어떤 방법을 사용하면 좋을까요?

두 방식을 모두 사용해본 결과 저는 이런 결론을 내릴 수 있었습니다. 

 

HighorderComponent

장점	1. 컴포넌트를 사용하는 입장에서 고차컴포넌트의 존재를 전혀 알지 못한다.
단점	1. 상황에 따라 다른 일을 수행해야하는 경우 외부에서 값을 inject해주기가 힘들다. 2. 이해해야하는 상용구와 규칙이 존재한다.

특히 highordercomponent를 설계할 때에는 안티패턴을 유의하며 코드를 작성해야합니다.

 

예컨대 highordercomponent에서 props를 추가 / 제거 / 수정하는 경우는 좋지않습니다.

컴포넌트를 고치거나 고차컴포넌트를 사용할 때 항상 그 prop을 기억하고 있어야한다는

병목지점이 추가되기 때문입니다.

 

WrapperComponent

장점	1. 상황에 따라 다른 값을 inject 해주는 것이 편리하다. (wrapper역시 컴포넌트이기 때문)
단점	1. 컴포넌트를 사용하는 입장에서 WrapperComponent의 존재를 알아야만한다. 2. 설계에 따라 컴포넌트를 사용하는 사람에게 너무 많은 통제권을 쥐어주게 될 수도 있다.

 

눈치가 빠르신 분들이라면 이미 알아채셨겠지만 두 방식은 모두 장점과 단점이 하나를 가리킵니다.

또 한 방식의 단점이 다른 방식의 장점이되기도 합니다.

즉 고차컴포넌트 방식과 , 래퍼방식은 서로 수행하는 일은 비슷하지만 그것을 수행하는 방법이 다릅니다.

 

따라서 적절한 상황도 다를것이라고 유추할 수 있습니다.

저는 간단하게 이런 방식을 통해서 뭘 사용할지를 구분 짓곤해요

 

1. 고차컴포넌트를 쓰는 경우

-> 상황을 타지않는 공통된 하나의 동작을 처리할 필요성이 있을 때 

-> 해당 동작에 대한 맥락을 다른 컴포넌트들이 전혀 알지 못 하게 만들고 싶을 때

 

2. 래퍼를 쓰는 경우

-> 공통된 동작이 존재하면서도 특정 상태에 따라 다르게 동작해야하는 경우

-> 해당 동작에 대한 맥락을 사용하는 곳에서 명확하게 드러내고싶을 때

-> 공통되게 하나의 동작을 하는게 아니라 해당 동작을 수행해야할 때 / 수행하면 안될 때가 나눠져있는 경우

 

예를 들면 예시로 사용했던 인증 로직의 경우

특정 페이지는 무조건 인증이 필요하다는 것을 알고 있고 / 모든 경우에서 인증을 무조건 수행하게하고싶다면

고차컴포넌트 패턴을 통해 공통된 인증 동작을 정의할 수 있습니다.

 

반면 코드를 읽는 사람 입장에서 이 페이지가 인증이 필요한지를 deepdive없이도 알 수 있게하고싶다면

컴포넌트를 보는 입장에서 이 페이지는 인증이 필요하다는 것을 한눈에 알 수 있게

래퍼 컴포넌트를 통해서 맥락을 알려줄 수도 있을 것입니다.

 

이렇듯 큰 궤는 같아보이는 요구사항이더라도 내 프로젝트의 환경과 요구사항에 따라

정답은 언제든지 바뀔 수 있습니다.

 

프로그래밍에는 유명한 말이 있죠?

"No Silver Bullet – Essence and Accidents of Software Engineering" 

---

😎 마치며

 

고차컴포넌트에 대해 알아보는 것을 넘어 다른 방식과의 차이점도 다루어보았습니다.

망치를 들면 모든게 못으로 보인다는 말이 있습니다.

망치를 손에 쥐고 있으면 모든 문제가 그 망치로 해결할 수 있는 "못"처럼 보인다는 말인데요

 

고차컴포넌트 패턴은 적절한 상황에서 큰 도움을 주는 좋은 "망치"일 수 있지만

모든 문제가 망치로 해결할 수 있는 "못"은 아니라는 것을 항상 기억해야할 것입니다.

 

읽어주셔서 감사합니다!

---

😎 레퍼런스

https://ko.legacy.reactjs.org/docs/higher-order-components.html