객체 리터럴을 통해 SOLID 하게 컴포넌트 선언하기

SOLID 원칙 중 OCP(개방-폐쇄 원칙)와 SRP(단일 책임 원칙)을 기반으로, props.type 에 따라서 컴포넌트를 import 해오는 코드를 정리해보았습니다. 링크드인에서 해당 코드들을 발견하였는데, SOLID 원칙을 기반으로 논리적으로 정리해보았습니다.

해당 게시물의 댓글도 보았는데, 해당 코드가 좋다 혹은 나쁘다 혹은 취향이다. 다양한 의견이 존재하더라구요!

Bad Code

switch (props.type) {
  case "ADMIN":
    return <Admin />;
  case "USER":
    return <User />;
  default:
    return <NotFound />;
}

• switch case 로직의 약점

1. 확장에 취약: 새로운 컴포넌트 타입이 추가될 때마다 switch 문에 새로운 case를 추가해야 하므로, 비교적으로 유지보수가 어렵습니다. 이는 OCP를 위반하는 코드입니다.
2. 중복된 로직: 여러 case를 추가할수록 코드가 길어지고 복잡해지며, 각 컴포넌트를 하나씩 나열하는 과정에서 오류가 발생할 가능성도 증가합니다.

Good Code

const ComponentMap = {
  ADMIN: Admin,
  USER: User,
  NOT_FOUND: NotFound,
};

const Component = ComponentMap[props.type] || componentMap["NOT_FOUND"]; // props.type이 ComponentMap의 속성이 아닌 경우 대비
return <Component />;

• 객체 리터럴을 통한 개선

1. OCP 준수: ComponentMap 객체에 추가되는 컴포넌트를 간단하게 추가할 수 있습니다. switch 문을 수정할 필요 없이, 객체 리터럴에 key:value로 컴포넌트를 추가합니다.
2. SRP 준수: 컴포넌트 매핑 로직과 실제 렌더링 로직이 분리되어 각각의 역할이 명확해집니다.
3. 가독성 향상: 객체 리터럴을 사용함으로써 코드가 더 깔끔하고, 유지보수하기 쉬워졌습니다.

• 주의해야할 부분

1. 기본값 처리: ComponentMap 에 props.type의 속성이 존재하지 않는 경우에 대비해야합니다. 처리되지 않는 케이스에 대비하여 ComponentMap[props.type] || componentMap["Not_Found"] 처리해주었습니다.

Better Code

const ComponentMap = {
  ADMIN: React.lazy(() => import("../components/Admin")),
  USER: React.lazy(() => import("../components/User")),
  NOT_FOUND: React.lazy(() => import("../components/NotFound")),
};
const Component = ComponentMap[props.type] || componentMap["Not_Found"]; // props.type이 ComponentMap의 속성이 아닌 경우 대비
return <Component />;

• lazy loading 을 통한 성능 향상

1. 지연 로딩(lazy loading): React.lazy를 사용하여 각 컴포넌트를 동적으로 로드하므로, 처음부터 모든 컴포넌트를 한 번에 로드하지 않습니다. 이 방식은 성능 최적화에 도움이 됩니다. 즉, 페이지가 커지거나 컴포넌트가 많아질수록 초기 로딩 속도가 개선됩니다.
2. 유용성: 컴포넌트가 많아질수록 전체 번들 크기가 커지고, 초기 로딩 시간이 길어집니다. React.lazy를 사용하면 필요한 시점에만 해당 컴포넌트를 불러오므로, 여러 컴포넌트를 동시에 로드하지 않고 필요한 컴포넌트만 지연 로딩할 수 있습니다. 특히 관리 패널이나 대시보드 같은 경우 다양한 컴포넌트가 동적으로 렌더링되는 케이스에서 유용합니다.
3. 컴포넌트가 많아질수록 유리함: 컴포넌트의 수가 많을수록 더 큰 성능 이점을 제공합니다. 많은 컴포넌트를 한 번에 로드하는 대신, 각 컴포넌트를 실제로 필요할 때 로드할 수 있어 성능 최적화에 효과적입니다.

평소 switch-case 문도, 객체 리터럴 활용도 자주하였는데, 이번 기회에 객체 리터럴 방식을 사용했을 때의 장점을 다시 생각해볼 수 있었습니다.

SOLID 원칙 또한 다시 한 번 생각해볼 수 있었네요!