조건부 렌더링 처리, 다들 어떻게 처리하시나요?

[Kimbangg]

안녕하세요! 리액트로 코드를 작성하다 보면 조건부 렌더링을 할 일이 정말 많죠.
저는 보통 AND 논리 연산자(&&)나 삼항 연산자(?:)를 이용해서 조건부 렌더링을 처리하곤 하는데요.

최근 회사 코드를 살펴보다가, 아래처럼 선언적인 방식으로 조건부 렌더링을 구현한 걸 봤어요.

const Component = () => {
  return (
      /**
       * 조건이 true일 경우 <A />를 렌더링합니다.
       * 조건이 false일 경우 null을 반환합니다 (렌더링하지 않음).
       */
      <If condition={someCondition}>
        <A />
      </If>
  );
};

이런 방식이 익숙하지 않아서, 기존 방식(논리 연산자나 삼항 연산자)과 비교했을 때 어떤 장점과 단점이 있는지 궁금하더라고요.
혹시 이런 선언적인 방식을 사용하시는 분들이 많으신지, 의견 나눠주시면 감사하겠습니다.

[endmoseung]

저는 사용성 관점에서 생각해봤어요.
사용성이 낮은 코드는 논리 연산자로 작성하는 게 더 적합하다고 봐요.
왜냐하면 이런 경우엔 어떤 조건으로 렌더링되는지 파악하기 간결하고, 논리 연산자가 일반적으로 많이 사용되기 때문에 가독성도 좋거든요.

반대로 사용성이 높은 코드에서는 선언적으로 상태를 넘겨주는 방식이 더 효과적일 것 같아요.
이렇게 하면 컴포넌트를 사용할 때 선언 방식이 모두 일관되게 맞춰지고, condition을 빼먹으면 에러가 발생해서 실수도 줄어들겠죠 ㅋㅋㅋ!
그리고 마치 객체지향에서 인터페이스로 상속하는 구조와 비슷해서 추후 유지보수에도 더 유리할 것 같아요.

[ssj9685]

저의 경우는 조건을 인지하는 방식에 따라 세가지로 나뉘는 것 같아요!

1. 단일 항목 단일 조건일 경우에는 삼항연산자나 논리연산자 사용

function Example(){
  return isLoading && <Loading/>
}

2. 단일 항목 복수 조건일 경우 switch

functino Example(){
 switch(state){
  case "READY":
     return <Ready/>;
  case "PROGRESS":
     return <Progress/>;
  case "DONE":
     return <Done/>;
}

3. 복수 항목 복수 조건일 경우 컴포넌트 작성

function Example(){
  <AccessManager country={["KR", "US", "JP"]} version="2.6.10" fallback={<Fallback/>}>
      <Content/>
  </AccessManager>
}

위의 사항들을 고려해봤을 때 위의 If 컴포넌트의 예시는 1번에 해당되는 것으로 보여서 저라면 삼항연산이나 논리연산을 사용할 것 같습니다!
결국 코드를 저만 읽는 것이 아니기 때문에 룰이 중요하고 코드를 인지하는 방식을 맞춰나가서 통일된 방식으로 코드가 작성되면 좋을 것 같습니다!

[raon0211]

저는 AND 연산자 && 또는 삼항 연산자가 보다 좋은 방향이라고 생각이 들어요.

Short-circuiting

먼저, <If /> 같은 컴포넌트를 사용하면 JavaScript에서 Short-circuiting이 보장되지 않아요. 그래서 TypeScript에서 그 하위의 children에서 타입이 좁혀지지 않아서 타입 안전함을 포기하게 돼요.

예시

JSX를 쓰니까 명확히 드러나지 않는 부분이 있는데요. 구체적인 JavaScript 코드로 살펴볼게요.

다음과 같이 value가 null이나 undefined가 아닌 경우에만 값: {value}을 렌더링하는 JSX 코드가 있어요.

<If condition={value != null}>
  <span>값: {value}</span>
</If>

JSX를 원래 JS 문법인 React.createElement로 표현하면 다음과 같이 표현되는데요. React.createElement(...) 함수 호출이 항상 이뤄지는 것을 볼 수 있어요.

React.createElement(If, { condition: value != null }, [
  // 이 라인은 value 값에 관계없이 항상 평가됨
  React.createElement('span', {}, `값: ${value}`)
]);

반대로, 다음과 같이 삼항 연산자를 사용하는 상황을 생각해 볼게요.

value != null ? (
  <span>값: {value}</span>
) : null

다음 원본 코드를 보면, 완전히 React.createElement(...) 함수 호출이 skip돼요.

value != null ? (
  // value == null 이면 이 함수 호출이 완전히 무시됨
  React.createElement('span', {}, `값: ${value}`)
) : null

그래서 더 언어 레벨에서 안전하게 코드를 다룰 수 있어요.

이렇게 TypeScript에서 타입 안전성을 보장하기 위해서 AND 연산자나 삼항 연산자를 쓰는 것이 더 좋은 방향이라고 생각해요.

[raon0211]

이 논의와 별개로.. 조건부 렌더링을 처리하는 방식은 한 프로젝트에서 하나의 방식으로 통일하는 것이 좋겠다는 생각도 덧붙이고 싶어요.

서비스를 만들 때 어떤 사람은 <If /> 를, 어떤 사람은 && 을 사용하면 코드의 일관성을 잃어버리고, 코드를 쓸 때 크게 중요하지 않은 고민들이 자꾸 드는 것 같아요. 이번에는 <If /> 로 해야 하나, && 로 해야하나..

[hoseungme]

JSX를 원래 JS 문법인 React.createElement로 표현하면 다음과 같이 표현되는데요. React.createElement(...) 함수 호출이 항상 이뤄지는 것을 볼 수 있어요.

이 말씀이 예전에 babel transpile을 거치고 나면 모든게 React.createElement()로 바뀌던 시절, 즉 리액트에서 import React from "react";를 강제하던 시절에는 사실이었던 걸로 기억하고 있는데요.

그 방식이 아니게 된 시점부터는 사실 JSX는 function call이 아니긴 합니다. 실제로

const content = <Content />;

if (condition) {
  return content;
}

한다고 해서 Content()가 실행되지는 않습니다. 이 내용이 원래는 없었던 것 같은데, 이젠 공식 문서에도 들어가 있네요.

물론 저는 @raon0211 님 말씀대로 이런 경우엔 JavaScript 연산자를 그대로 쓰는게 맞다고 생각합니다. 이유는 이따가 적어볼게요..

[raon0211]

말씀 덧붙여주셔서 감사해요!

import React from 'react' 가 강제되지 않으면서 구체적인 함수 호출이 바뀌기는 했지만, 여전히 _jsx(Component, ...) 형식으로 호출되지 않나요?

말씀하신 것처럼 Component() 처럼 렌더 함수가 바로 실행되지는 않지만, Props 객체나 Children에 넘어가는 값들이 미리 평가됨으로써 타입 안정성이 깨질 수 있는 가능성이 있다고 생각했어요.

[hoseungme]

맞아요. 런타임에선 아무 문제가 없지만, 말씀주신대로 타입스크립트를 사용하는 장점이 사라져버리죠. 아주 대표적으로 이런 경우요:

<If condition={data != null}>
  <Component data={data} />
</If>

function Component({ data }: { data: string }) {
  // ...
}

위에 말씀드린건 현시점 리액트와 JSX의 동작에 대해 바로잡고 싶었던 것 뿐이고, 저도 의견 자체는 완전히 같습니다.

[sjoleee]

저는 선언적인 컴포넌트 사용의 장점을 조금 생각해 봤어요.

인지적 관점에서 비교적 우수하다.

예를 들어, 아래와 같은 상태를 처리하는 컴포넌트를 구현한다고 가정해 볼게요.

• 결제 대기 상태

  • 주문이 PENDING 상태이고 결제가 WAITING 상태일 때
    • 결제 마감 기한 표시

• 배송 처리 상태

  • 배송 준비중: 예상 배송일 표시
  • 배송중: 운송장 번호 표시
  • 배송 완료: 배송 완료일 표시

// 기존 방식 (&&, 삼항 연산자 사용)
const OrderStatus = () => {
  const { status, payment, shipping } = useOrder();
  
  return (
    <div>
      {status === 'PENDING' && payment.status === 'WAITING' && (
        <PaymentWaitingMessage deadline={payment.deadline} />
      )}
      
      {status === 'PROCESSING' && (
        shipping.status === 'PREPARING' ? (
          <PreparingShipment estimatedDate={shipping.estimatedDate} />
        ) : shipping.status === 'IN_DELIVERY' ? (
          <InDeliveryInfo trackingNumber={shipping.trackingNumber} />
        ) : (
          <DeliveredInfo deliveryDate={shipping.deliveryDate} />
        )
      )}
    </div>
  );
};

기존 방식으로 작성된 코드는 가독성이 좋다고 생각되지는 않아요. 이유는 이렇습니다.

• 중괄호, 괄호, 연산자가 섞여 있어 인지적 부하를 줌
• 조건이 적힐 곳, 렌더링 될 컴포넌트가 적힐 곳이 명확히 구분되어 있지 않음
• 삼항 연산자의 경우 여러 조건이 순차적으로 처리되어 한 눈에 인식되지 않음

이제 선언적인 컴포넌트 If와 SwitchCase를 사용해서 표현해 볼게요.

// 선언적 컴포넌트 사용
const OrderStatus = () => {
  const { status, payment, shipping } = useOrder()

  return (
    <div>
      <If condition={status === 'PENDING' && payment.status === 'WAITING'}>
        <PaymentWaitingMessage deadline={payment.deadline} />
      </If>

      <If condition={status === 'PROCESSING'}>
        <SwitchCase
          value={shipping.status}
          caseBy={{
            PREPARING: (
              <PreparingShipment estimatedDate={shipping.estimatedDate} />
            ),
            IN_DELIVERY: (
              <InDeliveryInfo trackingNumber={shipping.trackingNumber} />
            ),
            DELIVERED: <DeliveredInfo deliveryDate={shipping.deliveryDate} />,
          }}
        />
      </If>
    </div>
  )
}

주관적일 수 있겠지만, 저는 이 방식이 훨씬 잘 읽힌다고 생각해요.

• If, SwitchCase가 명시적으로 '이제 조건부 렌더링이 발생할 거야'라고 말해줌.
• If, SwitchCase라는 네이밍이 일상 언어와 유사하여 직관적 이해 가능.
• 어디가 조건이고, 어디가 렌더링할 요소인지 명확히 구분됨.
• JSX의 구조를 따름.

위의 장점들 덕분에 기능 명세 없이 코드만 봐도 렌더링 조건을 알 수 있을 정도로 명확하게 표현할 수 있어요.
즉, 코드를 이해하는데 코드만 봐도 된다는 뜻입니다.

얼마 전에 어느 아티클에서 읽은 내용인데요, 원본 글을 찾지 못해 기억나는 대로 재구성하자면 이런 내용이었습니다.

어느 날 비개발자인 아내가 테스트 코드를 읽고 어떤 내용인지 이해할 수 있었는데, 이유는 it('should do something')과 같이 표현된 문장을 일상 언어처럼 이해했기 때문.

별도로 관리되는 문서는 최신을 보장할 수 없으며, 구현된 코드와 일치한다고 할 수 없어요.
따라서 현재 프로그램을 설명하는 가장 최신의 정확한 문서는 곧 코드라고 봐야 할 텐데요,
위처럼 코드가 readable하다면 프로그램의 맥락을 파악하고, 유지 보수하는 데에 큰 도움이 되지 않을까요?
(조금 이상적인 말일 수도 있겠네요...)

사실은...

저도 평소에 &&를 주로 씁니다. (다만 삼항연산자의 경우는 가독성 문제로 SwitchCase를 더 선호해요)
선언적인 조건부 렌더링 컴포넌트의 장점을 고민해본 것이라고 생각해 주시고...
이렇게도 생각하는구나~ 정도로 읽어 주시면 감사하겠습니다🙏

[airman5573]

예제에서 보여주신대로 삼항연산자를 겹겹이 쓰면 읽기가 어렵더라구요,
그래서 조건문이 확실히 드러나게 작성하는 걸 선호하는 편인데,
제안주신 IF 컴포넌트 외에도 즉시실행 함수를 사용해서 비슷하게 표현할 수 있습니다.
평소 읽는 js코드와 동일해서 개인적으로는 더 가독성이 좋더라구요!

const OrderStatus = () => {
  const { status, payment, shipping } = useOrder()

  return (
    <div>
      {(() => {
        if (status === 'PENDING' && payment.status === 'WAITING') {
          return <PaymentWaitingMessage deadline={payment.deadline} />
        }

        if (status === 'PROCESSING') {
          switch(shipping.status) {
            case 'PREPARING':
              return <PreparingShipment estimatedDate={shipping.estimatedDate} />
            case 'IN_DELIVERY':
              return <InDeliveryInfo trackingNumber={shipping.trackingNumber} />
            case 'DELIVERED':
              return <DeliveredInfo deliveryDate={shipping.deliveryDate} />
            default:
              return null
          }
        }

        return null
      })()}
    </div>
  )
}

[hoseungme]

저는 리액트에서 조건부 렌더링을 어떤식으로 작성하냐를 넘어서, "선언적이다", 그리고 "가독성이 좋다"라는 이유로 컴포넌트의 형태로 만들어 사용하는 것 자체에 대해 이야기하고 싶은데요.

지금까지 많은 프론트엔드 코드 리뷰와 논의를 지켜보면서, 어느 시점부터 공감이 잘 안가기 시작했던 부분이 바로 '특정 패턴을 일단 컴포넌트로 만든 후 그것을 선언적이라고, 또는 가독성이 좋다고 평가하는 것'이었습니다.

아주 적합한 예시로, 위에서도 바로 언급될 만큼 많은 분들이 익숙하신 switch case 컴포넌트가 있습니다.

<Switch
  value={value}
  case={{
    a: <A />,
    b: <B />,
    c: <C />,
  }}
/>

자, 아주 선언적이고 가독성 좋은 예쁜 코드가 작성되었네요! 어라, 그런데 역으로 생각해봅시다. 그럼 아래 코드는 선언적이지 않은가요? 또는 가독성이 좋지 않은가요?

switch (value) {
  case "a":
    return <A />
  case "b":
    return <B />
  case "c":
    return <C />
}

두 코드 모두 "value가 "a"일 때 <A />, "b"일 때 <B />, "c"일 때 <C />를 렌더링한다" 라는 결과를 가지고 있고, 그게 명확히 드러납니다. 즉, 선언적인 면에서 차이 없고, 가독성 면에서 차이가 없습니다. 유일한 차이는 JavaScript의 switch-case 문법을 리액트 컴포넌트로 작성했다는 것이죠.

잠시 리액트를 떠나서 생각해봅시다. 주어진 숫자 중에서 가장 큰 값을 뽑는 로직을 작성했을 때, 두 코드 중 무엇이 선언적이라고 느껴지시나요?

const arr = [1, 2, 3];
let max = 0;
for (let i = 0; i < arr.length; i++) {
  if (max < arr[i]) {
    max = arr[i];
  }
}

const max = Math.max(1, 2, 3);

저는 후자가 더 선언적이라고 생각합니다. 그 이유는, 전자는 결과를 어떻게 구하는지가 자세히 드러나지만, 후자는 원하는 결과가 무엇인지, 결과를 위해 무엇이 필요한지만 명확히 드러내고, 과정은 숨기기 때문이죠.

즉, '컴포넌트 사용'과 '선언적인 코드'는 서로 관계가 없다고 생각합니다. 반복되는 UI 렌더링 로직을 잘 추상화하여 선언적인 형태의 컴포넌트로 만들어서 사용할 때, 선언적인 코드가 되는 것이죠.

따라서 조건부 렌더링을 컴포넌트로 구현하는게 선언적인 측면, 가독성 측면에서 아무런 차이가 없으니, 다른 측면에서 어떤 이점이 있는지 살펴봐야 결정할 수 있을 것 같습니다.

첫 번째로 리렌더링 성능입니다. 우리는 부모 컴포넌트 전체가 불필요하게 리렌더링되는 것을 막기 위해, 자식 컴포넌트를 만들고 상태를 그 안으로 옮깁니다. 아래와 같이 말이죠.

function Parent() {
  return (
    <ChildA />
    <ChildB />
  );
}

function ChildA()  {
  const [state, setState] = useState(); // state가 변경되면 ChildA 컴포넌트만 리렌더링됨
  // ...
}

그런데 <If />, <Switch />와 같이 단순히 분기만을 해주는 컴포넌트들은 아무런 상태도 가지지 않습니다. 즉, 컴포넌트로 분리한다고 해서 리렌더링 성능에 아무 도움도 안됩니다.

두 번째로 타입 안전성입니다. 아래와 같은 discriminated union이 있다고 해봅시다.

type Query =
  { status: "fethcing" } |
  { status: "success", message: string } |
  { status: "failed", reason: string };

이때 JavaScript의 switch-case로 작성하면, TypeScript 컴파일러가 query.status 값에 따라 query.message, query.reason 프로퍼티의 존재 여부를 추론해줍니다.

switch (query.status) {
  case "fetching":
    return <Loader />;
  case "success":
    return <SuccessPage message={query.message} />;
  case "failed":
    return <ErrorPage reason={query.reason} />;
}

그런데 이를 <If />, <Switch /> 등의 컴포넌트로 작성하는 경우, 위와 같은 추론이 전혀 안됩니다. 물론 로직 상으로는 문제가 없기에 런타임에선 아무 에러도 발생하지 않지만, 타입스크립트의 존재 이유가 희석되는 것이죠.

즉, 오히려 컴포넌트로 조건부 렌더링을 했을 때 사용성을 넘어서 제품의 안정성까지 큰 손해를 보는 상황이 됩니다.

따라서 조건 분기를 컴포넌트로 작성하는 것은 선언적인 측면, 가독성 측면, 성능 측면, 안정성 측면 모두 아무런 이점이 없기 때문에, 그냥 JavaScript 기본 문법으로 분기하는게 더 옳다고 생각합니다.

[sjoleee]

지금까지 제가 선언라이팅(?) 당한 것이 아닌가... 되돌아보게 되는 코멘트네요. 새로운 인사이트 주셔서 감사합니다🙇

말씀해 주신 것처럼, switch-case 문이 단순하게 컴포넌트를 반환하는 경우에는 <SwitchCase />와 다를 바 없이 선언적이라고 볼 수 있을 것 같아요.
하지만 작성해 주신 switch-case문이 <SwitchCase />처럼 사용될 수 있어야 동일 선상에서 비교가 가능하지 않을까요?

  <div>
      {switch (value) { // 오류 발생
        case "a":
          return <A />;
        case "b":
          return <B />;
        case "c":
          return <C />;
      }}
  </div>

JSX에서의 switch-case 문

저는 이 논의가 UI를 조건에 따라 보여주기 위한 코드가 JSX내에서 선언적이고, 가독성 좋게 표현될 수 있는 방법에 대한 것이라고 생각했어요.
이 관점에서 보자면 switch-case 문은 표현식이 아니라 문이기 때문에 JSX 내부에서 직접 사용할 수 없고, 사용하려면 표현식으로 바꿔줘야 합니다.

1. 즉시 실행 함수를 사용하는 방법

<div>
  {(() => {
    switch (value) {
      case "a":
        return <A />;
      case "b":
        return <B />;
      case "c":
        return <C />;
    }
  })()}
</div>

이 경우는 개인적으로 JSX와 자바스크립트 문법이 섞여서 가독성이 비교적 좋지 않다고 생각해요.

2. 컴포넌트를 반환하는 함수로 호출하는 방법

const renderComponent = (value) => {
  switch (value) {
    case "a":
      return <A />;
    case "b":
      return <B />;
    case "c":
      return <C />;
  }
};

const RootComponent = ({ value }) => {
  return (
    <div>
      {renderComponent(value)}
    </div>
  );
};

이 경우는 UI 렌더링을 위한 코드가 JSX에서 분리되어 있기 때문에 가독성이 좋지 않다고 생각해요.

또한, 컴포넌트를 반환하는 함수는 일반 함수가 아니라 컴포넌트로 선언해야 한다고 생각해요.
일반 함수의 호출로 컴포넌트를 반환할 경우, 함수를 호출한 사용처(RootComponent)의 렌더링 사이클을 따르기 때문에 예상치 못한 동작이 발생할 위험이 있기 때문입니다.

3. 컴포넌트로 분리하는 방법

위의 renderComponent 함수를 컴포넌트로 만든다면(<RenderComponent />)
RootComponent에서 조건과 그에 따른 컴포넌트가 명시적으로 드러나지 않는다는 문제가 생겨요.

const RootComponent = ({ value }) => {
  return (
    <div>
      <RenderComponent value={value} /> // 어떤 컴포넌트를 언제 렌더링하는지 명시적으로 드러나지 않음
    </div>
  );
};

여기서 조건과 그에 따른 컴포넌트가 외부에 드러난다면 구조상 <SwitchCase />와 비슷한 것 같습니다.

---

말씀해 주신 타입 안정성 문제가 있어서 저도 SwitchCase를 사용할 때마다 고민이 되긴 합니다.
얼마 전에도 개발자 친구들과 '이거 타입 좁혀지게 못하냐~'라고 이야기 나눴던 기억이 나네요. 이게 너무나 치명적인 단점인 것에는 충분히 공감합니다😅

하지만 switch-case 문이 JSX에서 사용될 수 있는 형태로 바뀌어야 한다는 점을 고려해 보면...
<SwitchCase />가 가독성 측면에서 '아무런 이점이 없다'고 단정적으로 말하기는 조금 어렵지 않을까 싶어 댓글 남겨봅니다

[hoseungme]

코멘트에선 switch-case를 단독으로 사용했지만, 당연히 즉시 실행 함수와 함께 사용하는 것을 가정한 예제이긴 했습니다.

먼저, 저는 가독성을 '읽기 쉬운 정도'를 말하는 단어로 이해하고 있습니다. 즉, 코드를 읽기 쉽다는 것은 그 코드의 동작을 이해하기 쉽다는 것이죠.

그렇기에 저는 즉시 실행 함수가 함께 사용된다고 해서 읽기 어려워진다거나, 코드의 동작을 파악하기 힘들어진다고 생각하진 않습니다. 즉시 실행 함수와 함께 쓰이든, 혼자서 쓰이든 상관 없이, 그 코드의 동작은 그저 단순한 switch-case 분기일 뿐인걸요.

JavaScript 문법과 JSX가 섞이기 때문에 가독성이 낮아진다는 말씀도 주셨는데, JSX는 원래 전부 분리되어 관리되었던 마크업, 스크립트를 JavaScript 파일 한 곳에서 관리할 수 있도록 만들어주기에 오히려 기존 대비 높은 가독성과 쉬운 유지보수를 자랑하는 JavaScript의 확장입니다.

즉, JavaScript 문법과 결합하여 사용하면서도, 기존의 형태와 똑같이 작성할 수 있는 것(예: <p>{title}</p>)에 큰 이점이 있는 것인데, 둘이 섞여서 어려워진다는 말씀은 어불성설이라고 느껴집니다.

그리고 (저는 애초에 1번을 가정했었으니 논외긴 하지만) 2, 3번과 같이 JSX 수정이 번거로울 정도로 컴포넌트가 복잡해졌을 때, 그것을 별도 function 또는 컴포넌트로 분리해서 '가독성을 높히는 것'은 우리가 리액트에서 아주 흔하게 사용하는 패턴 중 하나죠.

즉, 말씀해주신 매우 간단한 예제들은 실제와는 거리가 멀고 이해를 위해 어느정도 끼워맞춰진 면이 크기 때문에 2, 3번의 불필요 여부와 가독성에 대해 논하기가 어렵다고 생각합니다.

결론적으로 1, 2, 3번 모두 가독성 측면에서 어렵게 느끼시는 이유가 사실 잘 공감이 되진 않습니다.