시점 이동 줄이기 | Frontend Fundamentals

[giscus[bot]]

시점 이동 줄이기 | Frontend Fundamentals

변경하기 쉬운 프론트엔드 코드를 위한 지침서

https://frontend-fundamentals.com/code/examples/user-policy.html

[ethan-sh-lee]

좋은 글 잘읽었습니다.

아래는 A. 조건을 펼쳐서 그대로 드러내기의 또다른 구현입니다. Solidjs의 Switch, Match 컴포넌트의 영향을 받았습니다.

결과 먼저 보여드리겠습니다.

function Page() {
  const user = useUser();

  return (
    <Switch>
      <Case when={user.role === "admin"}>
        <div>
          <Button disabled={false}>Invite</Button>
          <Button disabled={false}>Read</Button>
        </div>
      </Case>
      <Case when={user.role === "viewer"}>
        <div>
          <Button disabled={true}>Invite</Button>
          <Button disabled={false}>Read</Button>
         </div>
       </Case>
       <Case isDefault>{null}</Case>
    </Switch>
)

switch문 역할을 하는 유틸 컴포넌트 Switch와 Case를 추가하였습니다.

type CaseType = {
  when?: boolean;
  isDefault?: boolean;
};

const Case = ({
  children,
}: CaseType & { children: React.ReactNode }): React.ReactNode => {
  return children;
};

const Switch = ({
  children,
}: {
  children: React.ReactElement<CaseType>[];
}): React.ReactNode => {
  const defaultComponent = children.find((child) => child?.props?.isDefault);
  const resultComponent = children.find((child) => child?.props?.when);
  return resultComponent || defaultComponent;
};

[Johnyworld]

재밌는 컴포넌트 소개 감사합니다.
switch 문과 조금 더 비슷해보이려면, 비교 기준 값을 Switch 컴포넌트에서 받고 context 로 Case 컴포넌트로 뿌려주는 것도 방법이겠네요 :)

[jin-Pro]

안녕하세요. 예제 코드에 대해 질문이 있습니다.

B. 조건을 한눈에 볼 수 있는 객체로 만들기

function Page() {
  const user = useUser();
  const policy = {
    admin: { canInvite: true, canView: true },
    viewer: { canInvite: false, canView: true }
  }[user.role];

  return (
    <div>
      <Button disabled={!policy.canInvite}>Invite</Button>
      <Button disabled={!policy.canView}>View</Button>
    </div>
  );
}

해당 코드에서 policy 객체가 컴포넌트 내부에서 선언되기 때문에, 렌더링될 때마다 객체가 생성되고 제거되어 메모리 사용이 반복될 것으로 보입니다.

그래서 다음처럼 객체를 컴포넌트 외부 상수로 분리하는 방식이 더 효율적이지 않을까 고민이 됩니다:

const USER_POLICY = {
    admin: { canInvite: true, canView: true },
    viewer: { canInvite: false, canView: true }
  }

function Page() {
  const user = useUser();
  const policy = USER_POLICY[user.role];
  ...
}

다만 이렇게 되면 USER_POLICY 상수가 컴포넌트 외부로 이동하면서 코드 흐름을 한눈에 파악하기 어려워지는 시점 이동이 발생 하게 됩니다.

그래서 궁금한 점은 다음과 같습니다:

• 메모리 효율과 시점 이동 사이의 트레이드 오프라고 생각되는데, 모두들 시점 이동을 더 중요시 여기는걸까요?
• 상황에 따라 다르다. 라고도 생각이 드는데요, 이런 경우에는 팀 내 컨벤션을 통해 단일 방법으로 고정을 하는지도 궁금합니다

[gouz7514]

말씀하신 대로 해당 객체가 매번 생성되겠지만, 그 볼륨이 그렇게 크지 않기도 하거니와 해당 객체의 참조가 끝나면 가비지 컬렉션에 의해 회수가 될 거라서 큰 부담은 없다는 의견입니다.

USER_POLICY를 외부에 정의하면 메모리 측면에서도 이점을 가져오고, 시점 이동도 코드 예시처럼 복잡한 경우가 아니라 1번의 이동만 있어서 개인적으로는 어려워지지 않다고 생각합니다.

다만 저는 메모리 측면보다 코드 재사용에 좀 더 중점을 두고 개발하는 편이라, 해당 객체가 다른 곳에서도 재사용이 되지 않는다면 크게 단점이 없는 기존의 예시를 선호할 것 같습니다.

[jin-Pro]

각 접근 방식마다 고유한 장점이 있으므로, 메모리 사용 측면과 코드 재사용 측면에서의 트레이드오프를 비교해본 결과, 코드 재사용성을 우선시하여 개발을 진행하신다는 의미로 이해하겠습니다.

답변 주셔서 감사드립니다.

[calvinsnax]

개인적으로 B안이 좀 더 매력적인 것 같은데요, 그 이유는 A안은 구조적으로 코드가 반복될 뿐만 아니라 실제로도 조건의 상태가 변화할 때 렌더링할 Button 컴포넌트가 unmount되고 새로 mount되는 과정이 반복되어 인터랙션이 엮여있는 케이스에는 좋지 않을 것으로 보이기 때문입니다. 상태를 가지고 돔을 다룬다라는 React의 컨셉에도 B안이 더 적절해보여요.

여기서 B안을 조금 더 개선하자면

function Page() {
  const user = useUser();
  const policy = getPolicyByRole({
    admin: { canInvite: true, canView: true },
    viewer: { canInvite: false, canView: true }
  }, user.role)

  return (
    <div>
      <Button disabled={!policy.canInvite}>Invite</Button>
      <Button disabled={!policy.canView}>View</Button>
    </div>
  );
}

위와 같이 policy를 객체로만 선언하는 것보다 유틸 함수로 한 번 감싸주어 보다 type-safe하게 다루는 건 어떨까 싶습니다. Object[user.role] 이 구조가 개인적으로는 가독성이 좋지 않아보이기도 하고, role이 무엇인지가 드러나지 않는 날 것의 객체이기 때문에 약속된 구조를 함수를 통해 강제하는 것은 어떨까 생각해봤습니다.

type Role  = 'admin' | 'user' | 'guest'
const getPolicyByRole = (policy: Record<Role, string[]>, role: Role) => {
  return policy[role]
}
const policy = getPolicyByRole({
  admin: ['create', 'read', 'update', 'delete'],
  user: ['read'],
  guest: ['read']
}, 'admin')

함수의 형태는 이런 식으로 역할별 권한을 boolean이 아닌 string array로 정의해보는 것도 괜찮을 것 같아요. 본문의 맥락보다는 조금 동떨어진 의견이 아닐까 걱정됩나다만 누군가에게는 아이디어가 될 것 같아서 남겨봅니다^^

[HojinAn]

저 또한 코드의 반복을 지양하는 편이라 B안에 한표입니다 ㅎㅎ 제안해주신 방식대로 typesafe하게 생각해보는 방향도 상당히 흥미롭네요!

다만, 적어주신 내용에서 정말 마이너한 부분이지만 컴포넌트 mount, unmount 관련하여 이후 다른 독자 분들께 혼동을 드릴 수 있을 거 같은 한 가지 부분만 정정하고 싶은 부분이 있는데요!

A안은 ... 실제로도 조건의 상태가 변화할 때 렌더링할 Button 컴포넌트가 unmount되고 새로 mount되는 과정이 반복되어 ...

실제로 A안 코드에서 user의 state가 변경되어 role이 'admin'에서 'viewer'로(혹은 그 반대로) 변경된다고 해도 Button 컴포넌트는 unmount -> mount 되는 과정을 거치지 않습니다!

이는 React 재조정(Reconciliation)과 관련이 있는데요, 재렌더링 과정에서 기존 tree와 비교했을 때 element의 위치나, key등이 변경되지 않는다면 React는 기존 tree에 있는 컴포넌트를 재사용하게 됩니다 :)
(물론 'admin'에서 'default' (null)로 변경된다면, DOM 구조 자체가 아예 달라지므로 이때는 unmount가 발생하는 것이 맞습니다. 하지만 댓글의 뉘앙스상 'admin'과 'viewer' 간의 전환을 말씀하신 것으로 이해했습니다!)

지나가는 중에 혹시나 싶어 대댓글 남기고 갑니다..ㅎㅎ

React Reconciliation 관련 참고할만한 좋은 아티클 링크 / A안에 대한 condsandbox