Props Drilling 지우기 | Frontend Fundamentals

[giscus[bot]]

Props Drilling 지우기 | Frontend Fundamentals

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

https://frontend-fundamentals.com/code/examples/item-edit-modal.html

[LeeSeongJinCa]

안녕하세요. 저도 개발하다보면서 Props Drilling 에 대해서 꾸준한 고민이 있었습니다.
Toss 에서는 이 Props Drilling 을 어떻게 다루고 관리하는지 궁금함이 있고 이 질문으로 해소할 수 있으면 좋겠습니다.

---

질문: Props Drilling 이 3단계 이상에 걸쳐서 진행된 경우 어떻게 Props Drilling 을 지울 것인지?
Toss 에서는 중간의 불필요한 컴포넌트인 ItemEditBody 컴포넌트를 제거하고 컴포넌트 합성을 활용하여 Props Drilling 문제를 해결한 것으로 이해했습니다.

ItemEditModal -> ItemEditBody -> ItemEditList 를 ItemEditModal -> ItemEditList 로 변경

그런데 만약, 아래와 같이 동일한 Props를 계속해서 넘겨받는 Props Drilling 문제가 있다면 어떻게 관리할 것인지 궁금합니다.
예시) <ItemEditTrigger {...props} /> -> <ItemEditModal {...props} /> -> <ItemEditList {...props} /> -> <ItemEditItem {...props} /> -> <ItemEditForm {...props} />

예시를 작성하기 위해 컴포넌트 예시가 적절하지 않을 수 있지만, 이런 Props Drilling 이 계속된다는 상황을 표현하고 싶었습니다.

1. 이런 Props Drilling 상황이 나타났을 때, 어떻게 해결하는지?
2. 간단히 Props Drilling 을 해결하기 위해 Context 나 전역 상태 관리를 사용하는지?
   에 대해서 궁금합니다.

감사합니다.

[PIYoung]

개인적으로 전역 상태는 서로 다른 페이지 간에 데이터를 State의 형태로 공유 해야할 때 쓰는게 가장 좋은 사용 예시가 될거 같습니다.

Props Drilling이 조직내에서 반드시 해결해야만 하는 문제로서 평가되는게 아니라면 굳이 문제 해결을 위해 애쓸 필요도 없을 것 같구요. 만약에 반드시 해결해야만 하는 문제로서 평가가 됐다면 그 순간에는 전역 상태 관리 도구를 활용해도 무방한 상태까지 갔을 가능성이 있을거 같네요.

[youngduck]

@oungo
개발하면서 하나의 도메인에서만 쓰이는 데이터라도 props driling을 피하고 전역상태로 두는것이 전역상태값이 너무 비대해지는 것은 아닐까? 이에 따른 성능영향을 줄 수 있지 않을까?라는 고민을 종종 했었는데 의존성 관계를 나타낼 수 있다는 말씀을 듣고 새로운 관점을 얻어 가는것 같네요. 감사합니다.

정말 필요한 상황이라면 댓글들처럼 다른 페이지간의 데이터를 State 형태로 공유 해야할때 인것 같습니다.

[jungpaeng]

저는 다른 페이지 간 데이터를 공유할 때에도 전역 상태를 사용하지 않고 queryParams 또는 ContextAPI를 즐겨서 사용합니다.

전역 상태는 결국 리액트의 외부 상태인데, 이러한 값이 리액트와 싱크될 때 꽤 많은 문제를 일으키기도 합니다(많이 사용하는 useSyncExternalStore에 이슈가 있어서 jotai는 useSyncExternalStore를 사용하지 않는 방향으로 개발됐습니다: Link).

또한, 페이지 간 값을 공유하기 위해 전역 상태를 사용하는 것은 ContextAPI가 없던 시절 redux에 대부분의 데이터를 넣던 것이 대물림된 현상이라고 생각합니다.

이 부분에 대해서는 전역 상태를 사용하는 기준이 있으신가요? 토론 댓글 에서 좀 더 자세히 의견을 남겨두었습니다.

[jungpaeng]

안녕하세요, 아래 토론에 기반해서 해당 문서는 수정될 예정입니다.

2번에 대한 답이 될 수 있을 것 같아서 공유합니다. 관심 있으면 한번 읽어보셔도 좋을 것 같아요.

#29

[yoonjong-park]

초짜이지만 적어봅니다.
윗분들이 내용을 많이 적어주셨지만, 팀마다 상황이 다를 수 있기 때문에 몇 자 적습니다.

만약, 기존 프로젝트를 유지보수하는 와중에,
이미 redux를 사용하고 있고, redux를 통해서 Props Drilling 을 방지하고 있다면, 별도의 context API 를 사용하기보다는 redux를 사용하는 게 나을 것 같습니다.
물론, React의 합성 (Composition, 본문에서는 '조합' 으로 표기됨)으로 해결가능한지 먼저 체크해보고요.
이미 팀에서 그렇게 사용하고 있다면, 아마도, 내부에서 합의된 관리의 용이성을 좀 더 높게보고 방향을 잡은 걸 수도 있습니다.

그 방식이 좋은지, 안좋은지 원론적인 것은 조금 제쳐두어야 하지 않을까 싶습니다.
만약, 본인이 contextAPI를 적용하고 싶다면, 우선 동료들과 충분히 의견의 일치(consensus)를 이루고 나서 전환 혹은 적용해나가면 될 것 같습니다.

[Sangminnn]

안녕하세요, 저는 위에서 이야기 나누어주신 방향과 약간은 다른 이야기이지만 문서를 이런 방향으로 더 디벨롭해보면 어떨까 하는 생각에 의견을 남겨봅니다! (이미 Context API 예시로 변경될 예정이기때문에 이 방향이 적용될 수 있을지는 모르겠네요 :) )

저는 Props Drilling 없애기 문서를 보면서 Props Drilling을 해소하기위한 방법으로도 느껴지는 반면 오히려 불필요한 추상화 줄이기 와 같은 맥락이 더 와닿았어요.

ItemEditModal -> ItemEditBody -> ItemEditList 를 ItemEditModal -> ItemEditList 로 변경하는 과정에서 강조된 액션 아이템은 조합을 통해 Drilling을 줄이는 방향을 제시해주었지만 ItemEditBody 라는 단위의 추상화가 올바른 추상화였는가? 라고 생각해볼 수 있을 것 같아요.

itemEditBody 자체만으로 내부 구현을 감추고 복잡도를 낮춘다는 점도 추상화(컴포넌트화) 하는 것에는 의미가 있지만 위와 같은 경우에서는 Atomic한 Input, Button 컴포넌트는 충분히 그 자체 컴포넌트로도 재사용성의 관점에서 추상화되어있는 단위이기때문에 이들은 굳이 함께 감추지 않고 드러내면서 drilling을 최소화한다는 맥락을 함께 소개하면 이해에 도움을 줄 수 있겠다고 생각했어요.

이와 같이 추상화하는 과정에서 이를 컴포넌트화할 가치가 있는지를 판단하는 두가지 기준인

1. 복잡도를 낮춰주는가 ?
2. 재사용성이 증가하는가 ?

라는 기준과 조합의 미학을 함께 고민해본다면 문서에 작성해주신 조합을 통해 어느정도의 구현을 드러내는 것이 조금은 더 합리적인 결과물이라고 생각하게 될 것으로 보여 이러한 맥락을 함께 소개하면 코드 냄새를 맡고 개선하고자 할 때 판단에 있어 drilling을 줄이려면 조합을 활용하자 라는 관점에 매몰되지 않고 조금 더 생각의 균형을 맞추는 데에 더 도움이 될 수 있지 않을까하여 이러한 내용을 남겨봅니다.

[milooy]

Sangminnn님, 논의를 확장해주셔서 감사해요.

문서의 개선안 아래에

"조합 패턴은 단순히 Props를 전달하는 문제를 줄이는 것을 넘어, 불필요한 중간 추상화를 제거하여 개발자가 컴포넌트의 역할과 의도를 명확히 이해할 수 있도록 도와줘요.

를 추가하면 어떨까요?

이후에 '불필요한 추상화 줄이기' 전략 문서를 작성한 후에 이를 링크로 걸면 독자에게 도움이 많이 될 것 같아요.

[Sangminnn]

@milooy 긍정적으로 의견을 받아주셔서 감사합니다!

제안해주신 방향이 가장 좋아보이네요 :) 저도 추상화에 대한 문서가 있으면 더 좋겠다고 생각했는데 추후 추가될 예정이라면 말씀해주신 방향대로 하면 조금 더 도움이 될 것 같습니다.

혹시 현안 기준으로 개선안에 추가하는 것을 말씀해주신 것이라면 제가 PR을 올려보면 더 좋을것같고, 이후 개선 예정인 Context API를 활용한 문서를 기준으로 말씀주신 것이라면 제안드리는 것으로 마무리하고 혹시 개선안에 해당 내용이 포함되지 않는다면 그때는 PR을 올려보겠습니다.

[milooy]

네, 현안 기준으로 먼저 PR 올려주세요 :)
본 논의 내용을 링크 걸어주시면 더 맥락있는 리뷰가 가능할 것 같습니다 ㅎㅎ

[junjeeong]

이 글만 보아도 대체로 가독성 보다는 예측 가능성을 더 높은 우선순위로 보는 것 같다는 생각이 드네요!
ItemEditBody가 있으면은 추상화한 덕분에 ItemEditModal만 보았을 때에 봐야 할 로직이 줄어들어 더 쉽게 읽히지만 props drilling을 피해 결합도를 낮추겠다는 명목으로 추상화를 뺴버려 결론적으로 ItemEditModal에서 봐야 하는 로직은 더 많아졌으니까요!

[kickbelldev]

props drilling에 대한 전체적인 의견에 대해서는 공감하지만,

글의 예시는 컴포넌트 구조가 잘못됐다고 느껴져요.

ItemEditBody의 구조를 뜯어보면 Keyword를 입력하는 부분과 아이템 목록을 보여주는 부분이 Fragment로 단순히 묶여있어요.

이런 구조 때문에 컴포넌트 depth가 깊어져서 props drilling도 일어나게 된 것 같고 전반적인 맥락 이해가 어려워졌다고 생각해요.

저는 해당 컴포넌트를 해체해서 아래와 같이 코드를 작성할 것 같아요.

function ItemEditModal({ open, items, recommendedItems, onConfirm, onClose }) {
  const [keyword, setKeyword] = useState("");

  // 다른 ItemEditModal 로직 ...

  return (
    <Modal open={open} onClose={onClose}>
      <ItemEditSearch
        keyword={keyword}
        onKeywordChange={setKeyword}
        onClose={onClose}
      />
      <ItemEditList
        keyword={keyword}
        items={items}
        recommendedItems={recommendedItems}
        onConfirm={onConfirm}
      />
      {/* ... 다른 ItemEditModal 컴포넌트 ... */}
    </Modal>
  );
}

function ItemEditSearch({
  keyword,
  onKeywordChange,
  onClose,
}) {
  return (
    <div style={{ display: "flex", justifyContent: "space-between" }}>
      <Input
        value={keyword}
        onChange={(e) => onKeywordChange(e.target.value)}
      />
      <Button onClick={onClose}>닫기</Button>
    </div>
  );
}

function ItemEditList({
  keyword,
  items,
  recommendedItems,
  onConfirm,
}) {
  // ...
}

Keyword 상태가 ItemEditModal 내의 다른 부분에선 사용되지 않고 다른 부분의 분량도 많다면

ItemEditSearch와 ItemEditList 컴포넌트를 묶고 Keyword 상태를 해당 컴포넌트에서 관리하도록 만드는 방향도 괜찮다고 생각해요.

이렇게 하면 컴포넌트 depth가 줄어들고 props drilling도 줄어들어서 코드 이해도가 높아질 것 같아요.