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

[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]

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

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

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

[hoseungme]

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

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

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

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

[kimjihyo]

두 분 대화 아주 잘 읽었습니다 ! 중간에 언급된 “사실 JSX는 function call이 아니긴 합니다”라는 부분에서, 혹시 나중에 글을 읽으시는 분들이 오해할 수도 있을 것 같아 조금만 보완해봅니다.

const content = <Content />;

if (condition) {
  return content;
}

위 예제에서 는 컴포넌트 함수 자체가 즉시 실행되지는 않지만, JSX는 컴파일 시점에 React.createElement나 _jsx() 같은 JSX 생성 함수로 변환되고, 이 함수는 런타임에서 즉시 호출됩니다.

그래서 즉, 조건문이나 삼항 연산자 등으로 JSX 표현식을 감싸면 JSX 생성 함수의 호출 자체를 생략할 수 있는 것이 @raon0211 님 의견의 핵심인 것 같습니다.

또한, React.createElement와 _jsx()는 내부 구현이 다를 뿐, 이 맥락(조건부 렌더링에서의 평가 시점)에서는 본질적으로 동일하게 동작하므로, 두 방식 간에는 큰 차이가 없다고 보입니다.

[JaeHye0k]

이해를 돕기 위해 좀 더 구체적인 예시 코드 첨부합니다

선언적 컴포넌트 사용

• 코드:

let value: number | undefined | null;

<IF condition={value != null}>
  <A value={value} /> {/* Type 'number | null | undefined' is not assignable to type 'number'. */}
</IF>

function A({ value }: { value: number }) {
  return <span>값: {value}</span>;
}

• 트랜스파일링 결과:

let value; // number | null | undefined

_jsx(IF, {
    condition: value != null,
    children: _jsx(A, {
      value: value // number | null | undefined (타입이 좁혀지지 않음)
    })
});

연산자 사용

• 코드:

let value: number | undefined | null;

value != null && <A value={value} />;

function A({ value }: { value: number }) {
  return <span>값: {value}</span>;
}

• 트랜스파일링 결과:

let value; // number | null | undefined

value != null && _jsx(A, {
  value: value // number (단축평가에 의해 타입이 좁혀짐)
});

[hoseungme]

두 분께서 제 말을 오해하신 것 같습니다. JSX transform과 component call에 대해서만 최신화된 내용에 기반하여 정정을 한 것 뿐이지, raon0211님 의견의 핵심은 저도 알고 있고, 그것에 100% 동의한다고 이미 말씀 드린 바 있습니다.

그리고 제가 말씀드린 function call은 'component function call'입니다. _jsx는 props가 평가는 되지만 component function이 호출되는 것은 별개입니다. React.createElement와는 완전한 차이가 있습니다.

제 의견의 핵심도 이해해주셨으면 합니다. 좋은 피드백 감사드립니다.

[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>
  )
}

[Einere]

윗 댓글처럼, 해당 코드는 패턴 매칭을 이용해 깔끔하게 정리하는게 더 좋은 방법으로 보여지네요..!

[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번 모두 가독성 측면에서 어렵게 느끼시는 이유가 사실 잘 공감이 되진 않습니다.

[foriequal0]

저는 약간 좀 더 논쟁적일(?) 수 있는 절차지향적이고 mutable 한 스타일 사용중입니다.

#4 (reply in thread) 에서 @hoseungme 님이 짚어주신 것과 같이 React 에서는 컴포넌트를 JSX에서 사용한것과, 컴포넌트 함수가 호출돼서 생성되고 및 렌더링 되는 동작은 별개더라구요.
어떤 방법이든 결국 동일한 JSX 트리를 리턴하기만 하면 되고, 함수에서 반환 되기 전이라면 JSX도 평범한 JS 객체니 자유롭게 조작해도 상관 없더라구요.
그리고 삼항연산자, IIFE 역시도 평범한 JS의 흐름제어 구문이니까, 절차지향적이고 mutable 한 JS라고 해도 JSX를 구성하는 JS 구문들의 평가 순서가 크게 다르지만 않으면 결과가 동일하리라 생각했습니다.
삼항 연산자, JSX 안에서 IIFE 인라이닝, <If> 같은 조건부 컴포넌트 같은 스타일들이 mustache.js, jinja2, PHP 같이 문자열 스트림으로 HTML을 싱글패스(?) 렌더링하던 스타일의 연속선 아닐까 하는 생각을 하면서요.

그래서 위에서 나온 예시들 몇가지를 제 스타일로 작성하면 #4 (comment) 이 예시코드는 다음과 같이,

function Component() {
  if (someCondition) {
    return <A />
  }
};

#4 (comment) 이 예시코드는 다음과 같이 작성하겠습니다.

function OrderStatus() {
  const { status, payment, shipping } = useOrder();
  let waitingMessage;
  if (status === 'PENDING') {
    if (payment.status === 'WAITING') {
      waitingMessage = <PaymentWaitingMessage deadline={payment.deadline} />;
    }
  }

  let deliveryInfo;
  if (status === 'PROCESSING') {
    if (shipping.status === 'PREPARING') {
      deliveryInfo = <PreparingShipment estimatedDate={shipping.estimatedDate} />;
    } else if (shipping.status === 'IN_DELIVERY') {
      deliveryInfo = <InDeliveryInfo trackingNumber={shipping.trackingNumber} />;
    } else {
      deliveryInfo = <DeliveredInfo deliveryDate={shipping.deliveryDate} />;
    }
  }

  return (
    <div>
      {waitingMessage}
      {deliveryInfo}
    </div>
  );
};

마찬가지로 조건문 뿐 아니라, map, filter, reduce 함수들도 별로 좋아하진 않아서 평범한 반복문 사용합니다.

function EvenOdd(props: { lines: string[] }) {
  const children = [];
  for (let i = 0; i < props.lines.length; i++) {
    if (i % 2 === 0) {
      const even = <Even value={line} />;
      children.push(even);
    } else {
      const odd = <Odd value={line} />;
      children.push(odd);
    }
  }

  return (
    <div>{children}</div>
  );
};

[saengmotmi]

@foriequal0 사실 리액트에서 이야기 하는 '선언적'인 스타일이라는 것은 UI 컴포넌트를 다룰 때의 선언적인 측면을 이야기 하고 있다고 생각하는데요(ex. document.createElement 등)
렌더링이 멱등하다는 보장만 있다면 그 과정은 어떻게 되든 상관 없기 때문에 작성해주신 코드들 또한 전혀 문제 될 건 없다고 봅니다. 리액트 컴파일러가 변환한 코드들 또한 저런 식으로 되어 있기도 하고요.

다만 코드가 수정을 겪는 과정에서 값을 받아주는 변수와 값을 조작하는 로직 간에 응집이 깨지거나 알아보기 힘들어질 가능성이 높으니 이런 부분은 잘 다루어 사용해주는 것이 좋겠지요 :)

[nninnnin]

'별로 좋아하진 않아서' 가 이유라기에는 마지막 예시를 map filter로 고쳤을 때 가독성이랑 작성 시 편의성, 의도치않은 변경 가능성 제거 등 너무 큰 장점들을 희생하시는게 아닌가 싶네요.

[nninnnin]

function EvenOdd(props: { lines: string[] }) {
  const rendered = lines.map((line, index) => {
    const isOdd = index % 2 === 1;
    const isEven = index % 2 === 0;

    if (isOdd) return <Odd value={line} />;
    if (isEven) return <Even value={line} />;
  });

  return <div>{rendered}</div>;
};

반복문을 선호하시는 이유가 무엇인지는 모르지만 나름 '반복문 스타일' 로 작성된 map 로직이 아닐까 합니다.

[foriequal0]

@saengmotmi 코멘트 감사합니다. 가독성과 응집성이 중요하단 것에는 이견이 없습니다. 상황에 따라 평범한 제어구문이 괜찮은 선택지일 수도 있다는걸 제시하고 싶었습니다.

제 스타일로 DOM 과 CSS 의 트리구조에 예민한 경우를 다룰 때에는 아래 예시처럼 코드를 읽는 흐름이 구조를 따르지 않는게 단점인 것 같더라구요. 장점으로는 탭 깊이와 괄호가 한결 얕아지고, 디버거를 꽂아 한 스텝씩 따라가기 더 쉽고, 조금 더 까다로운 제어구문을 적용하기가 쉽고(양날의 검이겠네요), 성능에 미미하게나마 도움이 된다는게 있겠습니다.

function Foo(props: { lines: string[] }) {
  const childen = [];
  for (const line of props.lines) {
    const li = <li className="item">{line}</li>;
    children.push(li);
  }

  return <ul className="list">{children}</ul>;
}

@nninnnin
이 경우에는 제시해주신 버전이 좀 더 가독성이 좋다는데 동의합니다. TypeScript 를 사용중이라면 rendered 변수에 타입추론이 잘 되는것도 장점이겠구요(if (isEven) 을 else 로 바꾼다면요). map/filter 가 많은 경우에 추가적인 의미를 전달하는것도 장점이구요 (반복간에 부수효과가 없음 등). 이런 경우에는 저도 map/fliter 를 사용합니다. 다만 남들보다 제 사용 기준이 조금 높은 것 같아서 선호하지 않는다고 표현했습니다.

반복문이 map/filter 로 잘 변환되지 않는 경우의 예시를 가져오고 싶었는데 제가 예시를 잘 고르지 못한 것 같습니다.
반복간에 의존성이 있어서 map/fliter 로 변환하면 부수효과를 가지게 해야 한다거나, 반복 중에 제어구문(break/continue)을 쓸 필요가 있다거나, map/filter 체인이 중간 배열 할당을 수반하는걸 피하고 싶거나, map/fliter 체인 아래로 맥락을 내려보내야 한다거나 하는 경우들이 있더라구요.
이런 상황이 많지 않으면 좋고, 이런 상황을 피할 수 있게 코드를 재조직 할 수도 있지만, 불가피한 경우라면 반복문을 사용하는게 여러모로 좀 더 좋더라구요.

일반적인 제어구문들은 키워드가 확실히 있어서 문법강조도 잘 받고, 코드의 모양새가 특징적이어서 코드를 훑어보는데 유리해서 선호합니다.
map/filter 나 삼항연산자들은 괄호나 sigil 밀도가 높아서 문법강조가 많아도 코드 형태가 눈에 잘 들어오지 않더라구요.
그리고 반복문을 상황에 따른 정형적인 패턴 위주로 사용하는데 익숙해지다보니 코드의 특징적인 모양새 자체로 map/fliter 처럼 어떤 반복문의 속성을 읽어내기 어렵지 않더라구요.
디버거를 꽂아서 한 스텝씩 확인하기 쉬운것도 한 몫 하고, 미미하나마 성능면에서 도움이 되는것도 있구요.
체인의 map/filter 개수와 맥락이 바뀌면 prettier 가 인덴팅을 확확 바꿔버리는데, 반복문은 그런것에 좀 더 견고해서 diff 가 덜 생기는것도 장점입니다.

[nninnnin]

@foriequal0 말씀대로 for loop의 장점이 제어가 더 직관적이고 편리한 부분에 있지만, 컴포넌트 렌더링에서 그 결과물이 루프 안에서 너무 자유롭게 제어되면 결국 렌더링의 결과를 예측하기가 힘들어지지 않을까 싶습니다. 다수가 충분히 예측 가능한 조건부 렌더링 로직이 목적이라면 저는 체이닝을 이용할 것 같기는 한데, 사실 함수형 컴포넌트 안에서 for loop으로 렌더링을 제어해 본 경험은 없어서 특정 상황에서 요긴할수도 있겠다는 생각이 들면서 새롭네요. 아무쪼록 새로운 시각을 공유해주셔서 감사합니다.

[ssi02014]

다들 좋은 의견 많이 남겨주셔서 감사합니다. 개인적인 추가적인 의견을 남겨봅니다.
정말 순수하게 조건부 렌더링을 목적으로 하는 If, IfElse, SwitchCase와 같은 컴포넌트 사용은 저도 약간 회의적인 부분이 있는 것 같습니다.

하지만 동일하게 조건부 렌더링을 수행하지만, 특수한 목적을 갖는 컴포넌트의 경우에는 꽤 쓸모가 있다고 생각합니다.

예를 들어, AB테스트를 수행하는 ABTest 컴포넌트입니다.

<ABTest
  condition={condition}
  truthyComponent={<></>}
  falsyComponent={<></>}
 />

해당 컴포넌트는 사실 If 혹은 IfElse 컴포넌트와 다를게 없이 조건부 렌더링을 수행하는 컴포넌트입니다. 단, 차이라면 AB테스트라는 목적을 갖고, 네이밍 역시 이에 맞게 작성된 컴포넌트입니다.

이를 사용할 때 느낀 장점을 말씀드리자면, 실무에서는 서비스 내 여러 영역에서 AB테스트를 수행하는 케이스가 꽤 있을 것이라 생각합니다. 이때, AB 테스트를 하는 영역을 쉽게 추적 할 수 있다는 점입니다. (컴포넌트명 검색으로) 또한, 현재 코드만 봤을 때 추가적인 맥락 파악 없이 AB테스트를 수행하고 있구나를 빠르고 명확하게 파악 할 수 있습니다.

단순 조건식 혹은 논리 연산자로만 이런 케이스를 처리 했을 때 프로젝트 규모가 크다면 AB테스트 영역을 추적하는데 크고 작은 인지적 리소스가 들 수 있는데 이를 개선 할 수 있다고 생각합니다. 😄

[injunchoi98]

먼저 좋은 주제 남겨주셔서 감사합니다.

저는 조건이 단순할때는 논리연산자나 삼항연산자를 사용하는 편입니다. 논리연산자나 삼항연산자가 그 자체로 나쁘다고 생각하진 않습니다.

다만 앞선 분들이 말씀하신 것처럼 조건이 복잡해져서 분기처리가 다양해질 때가 문제인듯 합니다. 확장성 예측가능성 타입추론등이 모두 어려워지기 때문입니다.

그럴떄 저는 early return과 추상화된 컴포넌트를 이용하여 처리하는 편입니다. 이를 통해 결합도를 낮추고 코드 가독성을 높힐 수 있다고 생각합니다. 컴포넌트는 jsx 내에서 statement를 사용할 수 없기에 사용하는 컴포넌트 같은데, 앞선 예제들이 모두 컴포넌트 내에서 return 문을 하나만 사용함으로써 예측 가능성과 가독성이 오히려 떨어지는 것 같습니다.

이와 관련하여 제가 번역한 블로그 포스트 하나와 ui 컴포넌트 추상화를 위한 글 하나를 첨부하겠습니다.

https://wonderwalls.tistory.com/entry/컴포넌트-합성은-훌룡합니다-그런데
https://buildui.com/posts/avoiding-premature-abstraction-with-unstyled-react-components

[DevYuns]

여러 관점의 글이 있어서 재미있네요. 저도 복잡한 조건부 렌더링을 할 때 나름의 방식을 사용하고 있는데요.
단순한 케이스는 차치하고 여러 상태가 혼합된 조건에 따라 렌더링을 해야된다고 가정해볼게요.

저는 각 상태들의 가능한 조합을 하나의 변수 만들어서, ts-pattern의 match 문을 사용해서 표현하려고 합니다.
간략하게 표현하려다보니 다소 오버스러운 코드라고 보일 수는 있지만, 복잡한 케이스에서 타 팀원이 코드를 읽거나 조건을 수정할 때 꽤 유용하다는 생각이 들었습니다.

다른 분들은 어떻게 생각하시는지 궁금합니다.

const Component() {
  const [isLoading, setIsLoading] = useState(false)
  const [hasError, setHasError] = useState(false)
  const [data, setData] = useState(null)

  useEffect(() => {
    setIsLoading(true)
    fetch('https://api.example.com/data')
      .then(response => response.json())
      .then(data => {
        setData(data)
      })
      .catch(() => {
        setHasError(true)
      })
      .finally(() => {
        setIsLoading(false)
      })
  }, [])


  const viewState = useMemo(() => {
    if (isLoading) {
      return 'loading'
    }

    if (hasError) {
      return 'error'
    }

    return 'success'
  }, [isLoading, hasError, data])

  return (
    <>
      {match(viewState)
        .with('loading', () => <LoadingView />)
        .with('error', () => <ErrorView />)
        .with('success', () => <SuccessView data={data} />)
        .otherwise(() => null)}
    </>
  )
}
}

[ayden94]

이 논의에 영감을 받아, discriminated union 타입을 안전하게 분기 처리할 수 있도록 createSwitchMatch 함수를 구현해봤습니다.
특정 키(예: "status" 등)를 기준으로 조건을 분기하며, 각 분기에서 타입이 정확하게 좁혀지도록 동작합니다.

✅ 핵심 기능

• LiteralKeys를 통해 분기 가능한 리터럴 키 자동 추출
• 각 Match에서 타입이 정확히 좁혀짐
• 중복된 case 사용 시 런타임 에러로 감지

🔧 구현

export function createSwitchMatch<T, K extends LiteralKeys<T>>(data: T) {
  function Switch({ children, when, fallback = null }: SwitchProps<T, K>) {
    children.reduce((acc, { type, props }) => {
      if (type !== Match) throw new Error("Match 컴포넌트만 사용할 수 있습니다.");
      if (props.case) {
        if (acc.includes(props.case)) throw new Error(`Duplicate Match key: ${props.case}`);
        acc.push(props.case);
      }
      return acc;
    }, [] as Array<K>);

    return children.find(({ props }) => props.case === data[when]) ?? fallback;
  }

  function Match<V extends ExtractValues<T, K>>({
    children,
  }: {
    case: V;
    children: (props: ExtractByKeyValue<T, K, V>) => React.ReactNode;
  }) {
    return children(data as ExtractByKeyValue<T, K, V>);
  }

  return { Switch, Match };
}

export type ExtractValues<T, K extends keyof T> = T extends any ? T[K] : never;

type IsUnion<T, U = T> = T extends any ? [U] extends [T] ? false : true : false;

export type ExtractByKeyValue<T, K extends keyof T, V> = 
  T extends any 
    ? IsUnion<T> extends true
      ? T[K] extends V 
        ? T 
        : never
      : V extends T[K]
        ? T
        : never
    : never;

export type GetLiteralKeys<T> = {
  [K in keyof T]: T[K] extends string 
    ? string extends T[K] 
      ? never 
      : K
    : T[K] extends number
    ? number extends T[K]
      ? never
      : K
    : T[K] extends boolean
    ? boolean extends T[K]
      ? never
      : K
    : T[K] extends bigint
    ? bigint extends T[K]
      ? never
      : K
    : T[K] extends symbol
    ? symbol extends T[K]
      ? never
      : K
    : never;
}[keyof T];

export type LiteralKeys<T> = [GetLiteralKeys<T>] extends [never] ? keyof T : GetLiteralKeys<T>;

💻 사용 예시

@hoseungme 님이 제시하셨던 Query 타입을 처리할 수 있을 것인지를 가장 먼저 염두에 두고 작성했습니다.

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

function ApiStatus({ response }: { response: ApiResponse }) {
  // K는 자동으로 "status"로 추론됨
  const { Switch, Match } = createSwitchMatch(response);
  
  return (
    <Switch when="status" fallback={<div>알 수 없는 상태</div>}> {/* (property) when: "status" */}
      <Match case="fetching">
        {(props) => <Spinner />}
        {/* (parameter) props: { status: "fetching" } */}
      </Match>
      
      <Match case="success">
        {(props) => <Alert type="success">{props.message}</Alert>}
        {/* (parameter) props: { status: "success", message: string } */}
      </Match>
      
      <Match case="failed">
        {(props) => <Alert type="error">{props.reason}</Alert>}
        {/* (parameter) props: { status: "failed", reason: string } */}
      </Match>
    </Switch>
  );
}

Query가 유니언 타입이 아닐 때에도 문제 없이 동작합니다.

type Query = { status: string, message: string }

function ApiStatus({ response }: { response: ApiResponse }) {
  // K는 자동으로 keyof Query 로 추론됨
  const { Switch, Match } = createSwitchMatch(response);
  
  return (
    <Switch when="status" fallback={<div>알 수 없는 상태</div>}> {/* (property) when: keyof Query */}
      <Match case="fetching">
        {(props) => <Spinner />}
        {/* (parameter) props: Query */}
      </Match>
      
      <Match case="success">
        {(props) => <Alert type="success">{props.message}</Alert>}
        {/* (parameter) props: Query*/}
      </Match>
      
      <Match case="failed">
        {(props) => <Alert type="error">{props.reason}</Alert>}
        {/* (parameter) props: Query */}
      </Match>
    </Switch>
  );
}

⚠️ 한계점

type Query =
  | { status: "fetching", message: 1 }
  | { status: "success", message: 2 }
  | { status: "failed", message: 3 };

아쉽지만 이런 식으로 리터럴 타입이 여러 필드에 동시에 존재하는 경우, K는 "status" | "message"로 추론되어 자동 추론이 되지 않고, 명시적으로 createSwitchMatch<Query, "status">(...)처럼 제네릭을 직접 지정해야 합니다. 하지만 이건 큰 문제라고는 생각하지 않습니다.

type Query4 =
  | { status: string, message: string }
  | { status: string, reason: number };

위와 같이 discriminated union 타입이 아니지만 유니언 타입이기는 한 경우에는 대응이 불가능합니다. 아예 해결책 조차 생각나지 않습니다 ㅠ

결론

대부분의 경우, 특히 status, type 등 하나의 리터럴 키로 조건을 나누는 전형적인 discriminated union에서는 별다른 제네릭 지정 없이도 잘 작동합니다. 리터럴이 여러 필드에 분산된 특이한 구조가 아니라면 실전에서도 충분히 활용 가능하다고 생각합니다.

개선점이나 피드백은 언제나 환영입니다 :)