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 나 전역 상태 관리를 사용하는지?
   에 대해서 궁금합니다.

감사합니다.

[oungo]

위에 말씀주신 것처럼 동일한 props를 깊은 단계로 넘겨주는 상황이라면 ContextAPI를 사용해볼 수 있을 것 같아요.

각 컴포넌트들의 역할이 잘 분리되어 있어서 필요한 props만 전달해줄 수 있다면 위에서 설명하고 있는 Composition을 잘 활용하면 좋을 것 같은데요. 작성해주신 예시처럼 가장 상위에 있는 자식 컴포넌트가 받는 props를 전부 하위 컴포넌트들에게 그대로 전달해야만 하는 상황이라면 ContextAPI를 사용하는 것도 좋을 것 같아요.

전역 상태 관리는 props drilling을 해결하기 위해서 사용하기보다는 정말로 전역 상태로 관리가 필요할 경우에만 사용해야한다고 생각합니다.

[youngduck]

전역 상태 관리는 props drilling을 해결하기 위해서 사용하기보다는 정말로 전역 상태로 관리가 필요할 경우에만 사용해야한다고 생각합니다.
<=
해당 말씀에 대해서 그렇게 생각하시는 자세한 이유가 궁금합니다.

[rn0614]

ContextAPI를 무조건 전역으로 쓰지 않고 해당 Props Drilling이 발생하는 데이터의 부모컴포넌트에서 쓰면 됩니다. Compound Components Pattern을 참고하시면 됩니다.

[Jaymyong66]

@youngduck 전역 상태 관리를 쓸 때, 불필요한 복잡성과 예측하지 못한 사이드 이펙트가 발생할 수 있지 않을까요?
예를 들어 context api를 쓴다면 하위 어떤 컴포넌트에서 쓸지 파악하려면 해당 컴포넌트 파일을 열어봐야 할 것 같아요.
만약 규모가 크고 상태가 복잡하다면 한 곳의 전역 상태 변경이 전역 상태를 구독하는 또 다른 컴포넌트에도 영향을 줄 수 있으니까요
성능 이슈도 있을 수 있겠네욥