개발자
안녕하세요. 저는 프론트엔드 개발자가 되기 위해 공부중인 취준생입니다. 피드백을 적극 환영하기에 많은 피드백 혹은 의견을 많이 남겨주시면 감사하겠습니다. 저는 데이터 페칭을 어디서 하는 게 좋을지 고민 중이라 글을 남깁니다. 아래와 같이 3개로 글을 구성해봤습니다. 1. 현재 개발상황 2. 현재 저의 데이터 페칭 위치 3. 궁금한 점 1. 현재 개발상황 저는 개인 프로젝트로 Next.js와 React Query를 사용하여 개발하고 있습니다. 현재 Next.js의 App Router를 사용 중이며, 프로젝트 구조는 아래와 같습니다. app: page.tsx, layout.tsx components: 최소 2번 반복 사용되는 재사용 가능한 컴포넌트 container: 일반적인 컴포넌트 (조합 등) hook, service 등 2. 현재 저의 데이터 페칭 위치 현재 데이터 페칭은 최상단의 app -> page.tsx에서 수행하고 있으며, 자식 컴포넌트에는 데이터를 props로 전달하고 있습니다. 이러한 이유는 prop drilling이 발생하더라도 데이터 페칭을 한 곳에서 처리하면 코드 이해가 쉬울 것 같아서입니다. 현재로서는 전역 상태 라이브러리를 사용하지 않아 최대 4단계까지 prop drilling이 발생하고 있지만, 전역 상태 라이브러리를 도입하면 prop drilling 문제는 해결될 것으로 생각하고 있습니다. 추가적으로 현재 이렇게 구현하면서 data fetch할때 필요한 query값들도 최상단에서 관리해야하는 불편함이 있었습니다. -> 최상단에서 관리해야 하는 상태값이 늘어남 3. 궁금한 점 3-1. 아래의 2가지 data fetching 방법 중 어느것이 적절한지? 합리적인지 의견이 궁금합니다. - 최상단에서 Fetching - 장점 : 한 곳에서 Fetching하기에 코드 일관성, 가독성, 코드를 이해하는데 좋다고 생각 - 단점 : prop drilling, 추가적인 전역 상태 관리 해야한다고 생각 - 필요한 컴포넌트에서 Fetching - 장점 : 필요한 컴포넌트에서 fetching 하기에 prop driling과 같은 불필요한 코드 작성 할 필요 x - 단점 : 어떤 컴포넌트에서 fetching 했는지 파악하기 힘들어짐 3-2. 현재 최상단에서 모든 데이터 페칭을 하고 props로 전달하는 방식 vs 필요한 컴포넌트에서 데이터 페칭을 하는 두 가지 방식 중 어느 것이 더 많이 사용되는 패턴인지 궁금합니다. 3-3. React Query는 서버 상태 관리, 캐싱, Optimistic Update와 같은 기능을 위해 도입했습니다. 그러나 prop drilling을 해결하기 위해 React Query에서 가져온 서버 데이터를 전역 상태 라이브러리에 담게 되면 서버와 클라이언트 상태를 구분하는 의미가 없어지는 것 같다는 생각이 듭니다. 제가 잘못 사용하고 있는것인지 궁금합니다.
답변 3
리액트쿼리를 사용하신다는것이 곧 전역 상태관리라이브러리를 사용한다는 의미와 유사합니다 그러므로 아래로 이어지는 모든 질문은 전제가 잘못되어있다고 보아도 무방한 상태입니다 3-2에 대해서는 최상위에서 모든 페칭을 수행하게되면 전체서스펜스가 강제되기때문에 일반적으로는 컴포넌트에서 페칭을 수행합니다 나머지는 리액트쿼리의 역할을 조금 더 학습해보시면 자연스럽게 의문이 해소되실 것 같습니다 감사합니다
최상단은 안됩니다. 공부하시면서 지금은 모아서 보는게 편리하실 것 같긴한데 데이터 수가 몇백개 넘어가시는 시점이 오면 채감하실 겁니다. 정확하게는 A라는 데이터가 필요한 부분의 컴포넌트에서 가져와서 내려주면 되며 경우에 따라 최신화가 필요하면 재로드 혹은 PROPS나 상태관리로 내려주는 시점을 고민하시면 됩니다. ex) body > main > ul > li라고 가정할 때 body 구성정보는 body에서, main 구성정보는 main에서 li 구성요소이나 ul에서 가져와서 뿌려주면 ul 각 li에서만 필요한 정보면 각 li에서 이런식으로 하는게 기본입니다 이후 Next 를 도입해보시면 이러한 것들이 더욱 확실하게 분류되어 있습니다.
안녕하세요. 해당 질문에 대한 답변 드립니다. 현재 최상단의 app -> page.tsx에서 데이터 페칭을 수행하고, 자식 컴포넌트에 데이터를 props로 전달하고 있다고 하셨습니다. 이 방식은 코드를 이해하기 쉽지만, prop drilling 문제가 발생할 수 있으며, 상위 컴포넌트에서 관리해야 할 상태값이 늘어나는 단점이 있습니다. 지금은 api 호출이 별로 안될 수 있으나, 실제 현업에서는 api수가 수백, 수천개가 되는데 해당 api를 최상단에서 호출하게 되면 정말 말도 안되는 상황이 될 것 입니다. 많은 개발자들은 컴포넌트에서 직접 데이터 페칭하는 방식을 선호합니다. 이는 React Query와 같은 라이브러리를 사용할 때 더 자연스럽게 사용됩니다. 또한, React의 useEffect 훅과 결합하여 필요한 시점에 데이터를 가져올 수 있어 유연합니다. React Query를 사용하면서 전역 상태 라이브러리와 서버 상태를 구분하는 것이 중요합니다. 예를 들어, 서버 상태는 React Query로 관리하고, 전역 상태는 클라이언트 상태 관리(Redux, Recoil, Zustand)에 집중하는 것이 좋습니다. 필요하다면, 특정 데이터만 전역 상태로 관리할 수 있습니다. 하지만 이를 최소화하여 데이터의 일관성을 유지하는 것이 중요합니다. 그리고 프로젝트의 상황에 맞게 최상단에서 api 호출해서 관리하셔도 되는 프로젝트들도 분명 존재합니다. 항상 자신의 프로젝트와 상황에 맞게 유연하게 적용하는 것이 중요합니다. 열심히 공부하고 있는 모습이 멋집니다. 응원합니다! 😎😎
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 08월 06일
1. 데이터 페칭은 여러 가지 방식으로 처리될 수 있으며, 그 위치는 주로 애플리케이션의 구조 및 필요성에 따라 결정됩니다. 2. 최상단에서 모든 데이터를 가져오면 애플리케이션의 제어 흐름을 이해하기 더 쉽다는 장점이 있습니다. 다만, 이 방법은 prop drilling 문제를 초래하며 추가적으로 상태 관리 라이브러리가 도입되면 이 문제를 해결할 수 있습니다. 3. 각 컴포넌트에서 데이터를 가져오는 것 역시 유용한 패턴입니다. 왜냐하면 컴포넌트가 자체적으로 필요한 데이터만 로드하므로 불필요한 부분의 복잡성을 줄일 수 있기 때문입니다. 4. 필요에 따라 두 가지 접근법을 조합하여 사용할 수도 있습니다. 예를 들어, 전역 상태가 필요한 일부 핵심 기능에 대해서는 최상위에서 데이터를 가져오고, 나머지 개별 컴포넌트에 대해서는 해당 컴포넌트 내에서 데이터를 가져오는 방식을 선택할 수 있습니다. 5. React Query와 같은 라이브러리는 주로 서버 상태 관리와 캐싱에 초점을 맞추고 있습니다. 이렇게 가져온 데이터를 전역 상태에 저장하는 것은 필요에 따라 달라집니다. 그러나 일반적으로 서버 데이터와 클라이언트 상태 사이의 경계를 유지하는 것이 좋습니다. 결론적으로, 자신만의 답변을 찾는 데 도움이 되려면 애플리케이션의 요구사항과 복잡성, 그리고 팀에서 사용하기로 한 최선의 관행 등에 따라 다른 접근법을 고려해 보시는 것이 좋습니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!