개발자

컴포넌트 외부에서 Props로 데이터 받기 vs 컴포넌트 내부에서 데이터 fetch하기

2024년 02월 07일조회 1,082

부모 자식이 모두 서버컴포넌트일 때 부모가 데이터를 fetch하고 자식에게 props로 전달해 주는것과, 자식 컴포넌트 내부에서 데이터를 fetch하는것 중 어떤것이 확장성과 재사용성에 있어 더 좋은 컴포넌트인가요? 아래 코드에서 MyLikes는 내가 찜한 아이템, MyComments는 내가 작성한 댓글을 보여주는 컴포넌트 입니다. 처음엔 컴포넌트가 너무 구체적인 정보를 다루면 재사용성과 확장성이 떨어진다고 들어 외부에서 props로 전달하는 방식으로 만들었습니다. 그런데 MyLikes, MyComments는 내가 찜 한 아이템 데이터, 내가 작성한 댓글을 보여준다는 역할이 명확환 컴포넌트들이기 때문에 이미 구체적인 컴포넌트가 되었다고 생각됩니다. 이런 경우 이미 확장성, 재사용성이 떨어지기 떄문에 어떤 방식으로 데이터를 가져오던지 상관이 없는걸까요?

1// 부모가 Props으로 전달하는 경우
2const MyPage = async () => {
3  const token = new Token(new Cookie()).allToken;
4  const myComments = (await getMyComments(token)).payload.commentsWithEvents;
5  const myLikes = (await getMyLikes(token)).payload.data
6
7  return (
8    <div className="flex flex-col max-w-[1200px] px-4 w-full items-center gap-10 my-[100px]">
9        <MyLikes likes={myLikes} />
10        <MyComments comments={myComments} />
11    </div>
12  );
13};
14
15
16// 자식 컴폰넌트가 각각 fetch하는 경우
17const MyPage = async () => {
18  return (
19    <div className="flex flex-col max-w-[1200px] px-4 w-full items-center gap-10 my-[100px]">
20        <MyLikes />
21        <MyComments />
22    </div>
23  );
24};
25
26
27const MyLikes = async () => {
28  const token = new Token(new Cookie()).allToken;
29  const myLikes = (await getMyLikes(token)).payload.data
30
31  return (
32    <div> (중략) </div>
33  );
34};
35
36const MyComments= async () => {
37  const token = new Token(new Cookie()).allToken;
38  const myComments = (await getMyComments(token)).payload.commentsWithEvents;
39
40  return (
41    <div> (중략) </div>
42  );
43};
이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.
profile picture
익명님의 질문

답변 3

인기 답변

조용구님의 프로필 사진

안녕하세요 :) 확장성과 재사용성 측면을 본다면 "부모가 Props으로 전달하는 경우"가 좀 더 좋다고 생각합니다. MyLikes, MyComments UI를 재사용 할 수 있고, props의 인터페이스만 맞추면 API 변경에 유연하게 대응할 수 있을 것 같아요! 그런데 UI 자체가 재사용 가능성이 없다면 확장성과 재사용성보다는 응집성에 가치를 둬야 된다고 생각합니다. 그래서 UI 재사용 가능성이 없는 경우는 응집성이 높은 "자식 컴포넌트가 각각 fetch 하는 경우" 더 좋은 것 같아요!

인기 답변

조영훈님의 프로필 사진

Rifting state up, 즉 상태 올리기는 컴포넌트를 재사용하기 위한 중요한 테크닉 중 하나인데요. 리액트 공식 문서에 따르면 상위 컴포넌트에서 함수나 변수를 작성하고 하위 컴포넌트로 내려주는 것을 추천합니다. 다른 이야기를 덧붙이자면 대부분의 개발자도 재사용성, 확장성을 고려하여 그렇게들 많이 알고 있습니다. 하지만 리액트 문서에서의 Best practice는 하위 컴포넌트가 재사용 된다는 전제 하에 작성되었습니다. 재사용 되지 않는 코드 분할용 컴포넌트와 같은 하위 컴포넌트에게 props를 전달 해주는 것은 그저 불필요한 리렌더링을 일으키는 props drilling을 유발하게 되죠. 그래서 무작정 상위 컴포넌트에서 props를 전달 받는 것이 올바르다. 는 너무나 틀린 이야기고 상황에 따라 개발자가 판단 하여 사용해야 합니다. 본론으로 돌아가서 MyLikes와 MyComments의 경우는 저라면 컴포넌트 내부에서 fetch를 할 것 같습니다. 이유는 아래와 같습니다. - 상위 컴포넌트에서 전달 받고, Comment나 like가 변경 되었을 때(Mutation) refetching을 하게 되어 데이터가 변한다면 상위 컴포넌트의 연결된 자식 컴포넌트 전체가 불필요한 리렌더링이 일어납니다. - 말씀하신대로 두 컴포넌트 모두 각각의 API 호출과 결합도가 매우 높은 컴포넌트입니다. - 상위 컴포넌트와는 관계가 없는 로직이므로 상위 컴포넌트에서 작성된다면 해당 상위 컴포넌트의 가독성이 떨어지며 읽는 사람으로 하여금 혼란을 줄 수 있습니다. - 상위 컴포넌트에서 작성되면 상위 컴포넌트의 역할과 부담이 계속해서 점점 커질 것이고 코드 분할이 이루어질 수 없습니다. - 추후 props drilling으로 인한 리렌더링 퍼포먼스 이슈가 생긴다면 리팩토링 하기가 까다롭습니다. (사이드 이펙트도 고려해야하구요) 물론 상위 컴포넌트에서 해당 API 데이터를 사용하지 않는다는 가정 하이고, 사용한다면 props를 내려준다던가 다른 상태 관리 개념을 도입해야합니다. 추가적으로 API 명세에 따라 comment와 like 모두 요청 API경로가 다를 수 있습니다. 이런 경우 변하지 않는 API 전체 경로나 경로 일부를 상위 컴포넌트로부터 전달받아 해결합니다.

vriznet님의 프로필 사진

그건 케바케라 할 수 있는데 이에 대해 결정할 때에는 각 컴포넌트가 어떤 목적으로 만들어졌는지 그 컴포넌트의 의미는 무엇인지를 정의한 뒤에 그에 맞게 props 구조를 설계하는 것이 주안점이라 생각됩니다

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

AI 답변
커리어리 AI 봇 프로필 이미지

커리어리 AI 봇

GPT가 달아주는 답변입니다.

2024년 02월 07일

두 가지 접근 방식 모두 장단점이 있습니다. Props를 통해 데이터를 받는 경우, 부모 컴포넌트가 데이터 로드의 책임을 가집니다. 이 접근법은 컴포넌트 간의 종속성을 줄여주며, 각 자식 컴포넌트가 고립되어 독립적으로 작동하도록 합니다. 이로 인해 유연성 및 재사용성이 향상됩니다. 예를 들어, 서로 다른 페이지에서 MyLikes 컴포넌트를 사용하려면 해당 페이지의 상위 컴포넌트에서 데이터를 fetch한 후 MyLikes에 전달할 수 있습니다. 그러나, 한 가지 단점은 모든 서브 컴포넌트들에 필요한 데이터 fetch와 관리의 책임이 상위 컴포넌트에게 집중된다는 것입니다. 대형 애플리케이션에서는 이러한 구조가 복잡성과 관리 어려움을 초래할 수 있습니다. 반면, 각 컴포넌트에서 데이터를 fetch하는 경우, 각각의 컴포넌트는 독립적으로 웹 API와 상호작용하여 필요한 정보를 직접 가져옵니다. 이 방식은 개별적인 컴포넌트 변경이 다른 컴포넌트에 영향을 덜 주고, 상위 컴포넌트의 복잡성도 줄일 수 있습니다. 그러나, 이 경우 각 컴포넌트가 API를 fetch하는 방법과 token 등 자신의 state를 관리하는 방법에 대해 알아야 하므로 재사용성이 다소 떨어질 수 있습니다. 또한, 동일한 데이터를 여러 컴포넌트에서 요청하면 성능 문제가 발생할 수도 있습니다. 따라서 어떤 방식을 선택할지는 애플리케이션의 현재 및 예상되는 복잡성, 개별 컴포넌트의 범용성 및 재사용 가능성, 그리고 관리의 우선 순위 등 여러 요인을 고려하여 결정해야 합니다. 이들은 프로젝트 별, 경우에 따라 다르기 때문에 절대적인 정답은 없습니다.

목록으로

지금 가입하면 모든 질문의 답변을 볼 수 있어요!