#props

Next 서버 컴포넌트와 전역 상태관리

안녕하세요. Next15에서 서버 컴포넌트를 적극적으로 도입하여 프로덕트를 개발하고 있는데, 고민이 되는 부분이 있어 여러 분들의 도움을 얻고자 질문을 남깁니다. 서버 컴포넌트에서 받아온 데이터와 클라이언트 컴포넌트에서 사용하는 zustand가 적절히 사용되고 있는지 고민이 듭니다. 현재 GET 요청의 경우 각각의 서버 컴포넌트에서 fetch를 통해 진행하고, 해당 데이터를 자식 클라이언트 컴포넌트에서 사용할 경우 props로 내려 사용하고 있는데, 이때, 드릴링이 심해질 경우 zustand와 같은 전역 상태관리 라이브러리를 함께 사용하려고 합니다. 예를 들어, 서버 컴포넌트의 첫 번째 자식인 클라이언트 컴포넌트에서 zustand를 사용하고, 이후 자식 클라이언트 컴포넌트에서는 zustand를 통해 상태관리 할 때 자식인 클라이언트 컴포넌트의 업데이트가 진행되는 부분에서 try/catch를 통해 요청을 보내고, router.refresh()를 통해 서버 컴포넌트에서 데이터를 새로 받아옵니다. 이후 클라이언트 컴포넌트에서는 useEffect로 서버 컴포넌트에서 props로 받아온 데이터가 바뀌는 것을 감지하고, 해당 props를 zustand에서 사용하는 데이터로 업데이트하려고 하는데 문제가 될만한 점이 있을까요? 이와 관련된 링크나 답변이 있으시다면 감사히 받겠습니다!

프론트엔드 공부에 대해 궁금합니다.

작년 국비학원을 다니고 그 후 인강을 보면서 공부중입니다. 인강을 보면서 예를 들어 부모 컴포넌트의 코드를 작성하고 또 자식 컴포넌트를 만드는데 여기서 자식컴포넌트에 부모컴포넌트에 있는 값이 필요하네 그럼 부모컴포넌트에서 props로 넘겨 받아 자식 컴포넌트에서 쓰면 된다..... 이렇게 이해는 하고 제가 다시 혼자 한번 만들다고 이 컴포넌트에서 부모 컴포넌트에 있는 값이 필요하다 필요없다 이런 생각조차 나지 않더라구요. 다른 부분도 이런 부분과 마찬가지인데 초보자가 어떻게 공부를 하면 혼자 그래도 생각하면서 이럴땐 이런 코드를 이렇게 쓰면 되겠다..하면서 코드를 작성할 수 있을지 궁금합니다.

Next.js 코드 가독성..

안녕하세요 프론트앤드 1년차에 다가가고 있는 신입 개발자입니다. 현재 Next14를 사용하고 있으며 코드의 가독성, 효율성을 많이 고려하면서 코드를 짜려고하는데 너무 고민이 되네요 저보다 앞서서 달려가고 있는 개발자 선배님의 생각을 듣고싶습니다 ㅠㅠ... 2가지가 궁금합니다. 먼저 첫번째 이미지처럼 Version에 관련된 파일을 저렇게 분리했을 때 저는 Version의 최상위 Layout.tsx에서 모든 것을 선언하기가.. 너무 오히려 가독성이 안좋다고 생각을 하고 있습니다 즉, 변수나 함수를 모두 최상위 Layout.tsx에서 선언 및 정의를 해두고 props로 내려주는게 이상하다고 생각을 합니다. 변수, 함수, useEffect 모두 직접 해당 변수나 함수를 컨트롤하는 부분에서 선언 및 가공을 하는게 맞다고 생각을 합니다. 최상위 Layout.tsx가 너무 무거우면 오히려 나는 VersionDataTable에 관련된 변수나 함수만 보려고 하였으나 최상위 Layout.tsx를 보고 아 이게 VersionDataTable에 필요하구나 뭐가 필요없구나, useEffect의 의존성 배열까지 고려하는것이 불필요하다고 생각을 하고 있습니다.. 근데 같이 프론트 앤드 개발하시는 분께서는 '단기적으로 절대 코드가 변하지 않는다고 생각하면 그 말씀이 맞는데 그건 아니잖아요? 우리는 계속 유지보수를 할거고 그러면 결과적으로 A에서만 사용하던 변수나 함수들을 A,B,C에서 같이 사용할 수 있게 변경하게 되면 그때 변경하면 유지보수 측면에서 너무 안좋습니다. 최상위에 모두 선언이나 정의를 해두고 props로 내려주는게 맞다 이런 형식으로 코드를 작성하면 몇개월 뒤에 코드를 수정할 때 A가서 수정했다가 C가서 수정했다가 D가서 수정하실 거에요? 바로 알아보실 수 있겠어요?' 라고 말씀을 하시더라구요.. 물론 몇개월 뒤에 코드를 보거나 하면 제가 작성한 코드인데도 저는 헷갈리는 경우가 많습니다. 그러나 최상위에 모두 선언 및 정의해둬도 마찬가지 아닌가..? 유지보수 측면에서 뭐가 안좋은거지..? 라고 생각되게 됩니다.. 선배님의 말씀을 따라가고는 싶은데 이해가 안돼서요 제가 아직 기본기가 많이 부족한 상황이라 이 상황에서 말씀드리면 이론부터 말하며 설득시키기가 부족하다고 생각하기 때문에 말씀드리면 오히려 '저는 이렇게 생각해요 틀렸는데요?' 라고 말하는 것 같아 말다툼이 될 것 같습니다. 2. 밑 사진을 보면 modalTemplate라는 폴더, ConfirmTemplate이라는 폴더가 존재하는데요 이것에 대해서 저는 사용하는 용도에 따라서 Create면 Create Create와 Update를 동시에 할 수 있는거면 BundleCreateAndUpdate 이런 형식으로 각각의 파일을 생성을 하고 문법상 공유되는 부분은 중복이 되어서 실제로 보여주는 부분을 영역으로 나눠서 BasicOptions, SelectList, VersionDetail, VersionOptions로 나누고 각각의 파일에서 사용하는 부분만 불러와서 쓰는 형식으로 코드를 작성했습니다. 그러나 이렇게 용도에 따라 구분하지 않고 최상위 Layout.tsx파일 하나만 만들고 ModalType이라는 props를 받아서 ModalType이 create, update, create&update, delete ... 등 JSX에서 삼항 연산자를 써서 처리를 할수도 있습니다. 저는 ModalType으로 처음에 구분하다보니 나는 'create' 속성일 때 어떤 형식으로 되는지 코드로 보고싶은데.. 그러면 너무 뜯어서 봐야하더라구요 그래서 용도에 맞게 파일을 만들고 거기서 form을 불러오기만해서 중복 코드를 줄이는 방식을 택했습니다.. (더 나은 코드라고 생각했습니다.) 그랬지만 선배님께서 'ModalType으로 나누는게 더 좋아요 저렇게 지으면 가독성이 너무 떨어지고 파일의 이름이 너무 길어지잖아요 이상하지 않나요?' 라고 말씀을 하시더라구요... 물론 가독성은 사람마다 다른거 알고있습니다. 그러나 ModalType으로 나누기 시작하면 한도 끝도없이 나누고 ModalType이 delete일 때만 사용하는 함수, create일 때만 사용하는 함수 등 필요없는 함수도 너무 많아져서 용도에 맞게 파일을 구분하고 거기서 중복 코드만 최대한 줄이자! 라고 생각하여 코드를 작성했는데 이 내용도 말씀드려 봤지만 '가독성' 이라는 이유 하나만으로 너무 안좋다고 합니다.. 진짜 안좋은건가요..? Next 도 그렇고 프론트 앤드 너무 어렵습니다..

data fetching은 어디서 하는 게 좋은 것일까요?

안녕하세요. 저는 프론트엔드 개발자가 되기 위해 공부중인 취준생입니다. 피드백을 적극 환영하기에 많은 피드백 혹은 의견을 많이 남겨주시면 감사하겠습니다. 저는 데이터 페칭을 어디서 하는 게 좋을지 고민 중이라 글을 남깁니다. 아래와 같이 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에서 가져온 서버 데이터를 전역 상태 라이브러리에 담게 되면 서버와 클라이언트 상태를 구분하는 의미가 없어지는 것 같다는 생각이 듭니다. 제가 잘못 사용하고 있는것인지 궁금합니다.

[React] props vs (전역상태+커스텀훅)

안녕하세요. 다들 고생이 많으십니다. 코린이 질문하나 합니다. 제가 리액트 프로젝트를 진행하면서 처음에는 컴포넌트에 props drilling을 이용해 프로젝트를 만들었습니다. 만들고 나니 뭔가 나중에 이 프로젝트를 볼 때 부모 컴포넌트를 찾아가며 코드를 파악해야 하는게 좀 아쉽다고 생각하여 전역상태 + 커스텀 훅으로 변경하였습니다. 그런데 변경하고 나서 코드는 확실히 깔끔해지고 알아보기도 쉽긴 한데.. 콘솔을 찍어보면 처음 구현했던 것 보다 훨씬 많이 찍힙니다. 랜더링이 더 많이 일어나는거 같은데.. 이럴경우 그냥 처음처음 props drilling를 사용하는게 나을까요?

react 전역 상태 관리 도구 사용

안녕하세요~! 최근에 프론트엔드를 배우게 되어서 여쭤봅니다.. react 를 사용하면서 props drilling 을 겪고, 복잡한 코드가 되어 가는 중입니다. 궁금한 점은 zustand를 전역 상태 관리 도구로 사용하고 있는데 zustand를 어떻게 사용해야 잘 사용하는 것 일까요? 렌더링을 조금 깔끔하게 하고 싶어서 문의드립니다. 상황에 따라 다르겠지만 zustand를 많이 써서 state를 store 형태로 보관해서 사용하는게 좋을까요? 전문가들의 고견 부탁드립니다.(_ _)

Next.js 질문

아직 next의 개념을 잘 몰라서.. 혼란스러움에 질문드립니다..ㅠㅠ 전역상태에서 state를 꺼내서 사용하거나 react-query, pagination같은것들은 모두 csr로 변경해서 코드를 짜야하던데 그러다보니 page가 거의 use client로 도배되었는데요… 그럼 SSR의 장점들을 모두 잃어버리는건가요…? getStaticProps나 getServerSideProps들을 사용해서 이러한 문제들을 해결할 수 있다는데, 이것들로 해결해야하는걸까요..? 🥲

react-query로 이미지를 가져올 때, 이미지가 깜빡거리는 문제를 해결하고 싶어요.

React 프로젝트에서 차량 데이터 목록(차량 모델 사진, 차량명, ....등)을 보여주는 웹 프로젝트를 진행하고 있습니다. 차량 데이터 목록 화면에서 react-query를 통해 가져온 데이터는 (예시 데이터) const data = [{id: number, car_name: string, model_name, car_model_image: number...}, {.....} ] 이런식으로 가져와서 map을 통해 CarCard 컴포넌트에 데이터를 props로 보내어 현재 출력하고 있습니다. 여기서 이미지 같은 경우는 백엔드에서 차량 모델 이미지를 가져오는 api를 따로 만들어놓아서, props로 전달받은 car_model_image 즉, 차량 모델 이미지의 id를 통해서 차량 모델 이미지 api에 데이터를 요청해서 이미지를 출력하고 있습니다. 이때. 페이지를 전환하거나, 한 페이지에서 아무동작을 하지 않아도 게속 이미지가 깜빡거리면서 재렌더링이 되고, 계속 무한정으로 이미지를 호출하는 문제가 발생하였습니다. map을 통해 CarCard를 호출하고 CarCard 안에서 이미지를 호출함에 따라서 계속 이미지가 깜빡깜빡 거리는 것 같은데, 컴포넌트 안에서 이미지를 호출할 때 어떻게 하면 무한정으로 이미지를 불러오지 않도록 하고 깜빡거림을 없앨 수 있을까요 ?...어떻게 해결해야 할지 감이 안 잡혀요.... //차량 목록 페이지 한 부분 ... const { data } = useGetCarList(); //useQuery를 통해 서버에서 데이터 전달받음 // const data = [{id: number, car_name: string, model_name, car_model_image: number...}, {.....} ] 이런식 .... return ( <div> data.map((data: CarData) => { return ( <Carcard ascCarData={data} key={Math.random()} handleClick={() => handleClick(data)} isActive={true} /> ); }) </div> ) //Carcard 컴포넌트 const { data: carImage } = useGetCarModeImage(ascCarData.car_model_image); // 이미지 데이터 가져오기

리액트 리랜더링 질문

안녕하세요! 제가 개발중에 문제가 생겼는데 혹시 아시는분이 계시면 답변해주시면 정말 감사하겠습니다. 저는 녹음기능을 구현하고 있습니다. A(부모) 컴포넌트에서 상태를 정의하였고 const [mice, setMice] = useState(false) 자식컴포넌트인 A_1, A_2 에게 props로 상태를 넘겨줍니다. A_2에는 시작과 중지 버튼이 있는 컴포넌트 이고 시작버튼을 누르면 setMice를 true로 증지 버튼을 누르면 setMice를 false로 만드는 역할을합니다. A_1은 props로 전달받은 mice에 따라 mice가 true면 녹음내용을 화면에 뿌리고, mice가 false면 녹음을 중지합니다 문제는.. A_2에서 녹음 중지를 누르게 되면 mice가 false가 되고 A_1이 리랜더링 되면서 기존의 커서위치를 초기화 시키는 문제가 있습니다. 이걸 어떻게 해결해야할까요? 글을 좀 못쓴거같은데 읽느라 고생하셨습니다 ㅠㅠ

넥스트js에서 사용자 인증 페이지 구분

사용자 인증은 jwt토큰으로 하고 있습니다 현재는 serversideprops 또는 클라이언트 사이드에서 토큰을 가져와서 로그인 페이지로 보내고 있는데요 어느정도 모듈화가 필요한 것 같은데 마땅한 방법이 떠오르지 않아 질문 드립니다 제가 생각한 방법은 사용자 인증이 필요한 pathname을 array로 정리해 app.js에서 구분하려 하는데 더 좋은 방법이나 현재 사용하고 계신 방법이 있다면 공유 부탁드립니다

styled-components props 사용 시 prefix ($)

리액트 프로젝트를 진행하고 있고, styled-components 을 사용해 스타일링하고 있습니다. 저번 프로젝트에는 뜨지 않았던 prefix ($)를 붙이라는 warning 메세지가 뜨는데 $ 를 붙이는 것에 대해서 어떻게 생각하시나요? 주니어 개발자라 동향을 따라가는 게 좋을 것 같아 질문 남깁니다...!

react-hook-form 복잡한 form에서 궁금점이 있습니다 !

안녕하세요 현재 진행하는 프로젝트에서 form을 recoil로 관리하고있습니다. 이유는 form과 화면구성이 너무 복잡한 형태라 props drilling도 심하고 (부모에서 자식까지 5~7 depth) 관리해야하는 데이터가 많아 store에서 관리하고있습니다. react-hook-form이 복잡한 form에서 효율을 낸다고 해서 마이그레이션 해볼까 생각중인데 궁금점이 있어 작성합니다 ! 1. 이렇게 전역적으로 관리를 해야하는 복잡한 form에서도 좋은 효율을 내고 전역 상태관리 라이브러리보다 좋은 방향일까요?! (FormProvider 를 사용) 2. form에서는 input 필드만이 아닌, tab클릭, 드랍다운 클릭, 체크박스 클릭, 이미지 업로드, 라디오 클릭 등등 이러한 경우가 많은데 react-hook-form 을 사용해도 좋은 방향인가요?! 어떨때 react-hook-form을 사용하면 좋은지 궁금합니다 !

Next와 React-query의 prefetch에 대해

안녕하세요 ! Next14 버전과 tanstack-qeury를 이용해 프로젝트를 진행하던 도중 궁금한 점이 생겨 질문드립니다. Next의 서버 컴포넌트에서 data를 prefetching 하여 사용하려면 다음과 같은 단계를 밟아야 하는 것으로 알고 있습니다. 1. 서버 컴포넌트에서 queryClient.prefetchQuery를 사용해 데이터를 불러오고 이를 dehydrate하여 HydrationBoundary 내에 state로 넘겨준다. 2. 데이터를 사용하는 컴포넌트에서 useQuery로 동일한 데이터를 불러오면 해당 데이터는 prefetch 된 상태로 넘어와 이를 사용한다. 현재 이를 토대로 아래 예시코드와 같이 작성하여 사용중입니다. 이 때 하위 컴포넌트에서 prefetch한 데이터를 사용하려면 useQuery를 써야하기에, 'use client' 를 사용해야하고, 그렇게 되면 그 하위 컴포넌트도 전부 Client Boundary에 들어오게 되는 것으로 알고있는데, 그럼 "Next를 사용하며 얻을 수 있는 장점이 줄어들지 않나 ?" 라는 의문이 생겼습니다. 제가 사용법을 잘못 알고있다거나 Next의 개념에 대해 부족한걸까요 ? 또, HydrationBoundary로 감싸지 않고 queryClient.getQueryData를 이용해 직접 데이터를 가져와 이를 props로 전달해도 기능은 정상적으로 작동하는데, 이 둘의 차이점이 정확히 무엇인가요 ?

useSuspenseQuery의 SSR 요청

안녕하세요, Next.js (v13-14), react-query (v5), page router 환경일 때, useSuspenseQuery와 Suspense를 사용했는데 찾아보니 useSuspenseQuery는 컴포넌트 렌더링 시점에 데이터를 로딩하도록 설계가 되어 있어서 Next.js에서 getStaticProps or getServerSideProps 함수를 사용하지 않아도 서버에서 api 요청이 보내지는게 맞을까요? 제가 테스트해보니 위의 가정 했던 것 처럼 동작하는것을 확인을 했지만 문서에서는 그런 내용을 찾을 수가 없어서 질문을 올려봅니다. 감사합니다!

Next.js의 SSG와 react-query의 useSuspenseQuery

Next.js v14의 페이지 라우터 및 react-query v5의 useSuspenseQuery를 사용하여 Suspense를 사용할 때 페이지 컴포넌트에서 getStaticProps를 사용하지 않아도 SSG 빌드 타임에서 API request 하는 현상이 발생해서 찾아보니 useSuspenseQuery가 컴포넌트 렌더링 시점에 데이터 로딩하도록 설계가 되어 있기 때문에 빌드 타임에서 HTML을 만들 때 결국 API request 하게 되는 것이라고 이해했었는데 제가 이해한 부분이 맞을까요? react-query(tanstack-query)나 next.js의 공식문서에는 그러한 내용을 찾기가 어려워서 정확한 정보인지 알고 싶습니다!

react에서 복잡한 상태를 관리할때.. 한번에 관리? 분리해서 관리? (jotai, recoil, useState)

안녕하세요 react를 이용해서 복잡한 작성 페이지를 만들고있습니다. 아래의 타입은 예시입니다. type payload = { name: string; message: string; type: string; url: { pc: string; mobile: string; }; contents: { images: { url: string; name: string; }[]; buttons: { name: string; url: string; }[]; }; conditions: { ... }, .... }; 위처럼 복잡한 데이터를 서버로 보내줘야해서 데이터를 관리해야하는데 현재는 페이지내에 구조가 복잡하고 컴포넌트도 매우많아 props drilling이 너무 심해질거같아서 recoil, jotai와 같은 상태관리 라이브러리를 이용해서 작업을 진행하고있습니다. 이러한 상황에서 관리하는 데이터를 한객체에 모아서 관리하는게 좋은지 아니면 const nameAtom = atom(''); const messageAtom = atom(''); const typeAtom = atom(''); const urlAtom = atom({ pc: '', mobile: ''}); .... 처럼 일일히 쪼개서 관리하는게 맞는 방향인지 모르겠어서 질문드립니다 ! (사수가없어서 물어볼곳이없어요...) 현재는 아래와같이 쪼개서 작업한뒤 submit시에 합쳐주는 방식으로 구현해놓았는데 atom 갯수가 20개 정도 되버리니까 너무 복잡해보여서 이게맞나... 싶어서 질문드리게되었습니다.

next.js에서 interceptor 어떻게 사용하고 계신가요?

안녕하세요 page router 형식으로 프로젝트 진행 중 궁금한게 있어 게시글 남깁니다. 현재 프로젝트에서는 두가지 AJAX 요청이 존재하는데요. 한가지는 클라이언트 사이드에서의 요청(좋아요 누르기 기능 등)과 서버 사이드 렌더링을 위한 getserversideprops에서의 요청입니다. 문제는 인증 방식으로 엑세스토큰을 사용중인데 axios interceptor을 사용하려고 보니 하나의 interceptor로 두가지 요청을 커버하기가 어렵겠더라구요. 혹시 비슷한 경험이 있으신분들 어떻게 사용하셨는지 공유해주시면 감사하겠습니다.

리액트에서 어떤 걸 전역상태로 관리해야 하고, 어떤 걸 하지 말아야 할까요?

단순히 props drilling이 너무 과도해지거나 상태를 공유하기 힘든 상황일 때 협의를 통해서 사용하면 될지, 아니면 의미를 생각해서 전반적으로 전역으로 관리되어야 할 필요가 있는 데이터를 전역 상태로 관리해야 할까요? 이번에 공부 용으로 사이드 프로젝트를 진행하면서 자식 컴포넌트의 상태를 부모,조상으로 전달해줘야 하는 복잡한 컴포넌트가 하나 만들어지게 되었습니다.. (하나의 필드 안에 검색, 필터,select 등등이 있고 이를 동적으로 생성할 수 있는...) 상태를 공유할 수 있는 다양한 패턴을 통해서 해결이 가능하지만, 구현의 복잡도가 훨씬 높아진다는 생각을 했는데 이럴 때도 전역 상태를 사용해도 괜찮을까요? 사실 전역 상태로까지 관리할 데이터인가?에 대해서는 아니라고 생각하지만 사실 전역 상태라는 것이 구현의 복잡도를 줄여준다는 측면에서 만들어 진 것이라고 생각해서 내가 불편하면 사용하는게 맞지 않나? 라는 생각이 드네요 아니면 아예 구현 부분에서 잘못 되었던 걸까요? 컴포넌트 분리에만 초점을 맞추다 보니 이 점을 많이 신경쓰지 못한 것 같습니다..

Next.js RSC Network response관련해서 질문이 있습니다.

Next.js App router를 사용하고 있습니다. 간단한 검색기능을 구현하는 프로젝트를 진행 중인데 패칭 과정은 아래와 같습니다. 1. 자식 Client 컴포넌트에서 url의 searchParams(router.replace)를 변경하면, 2. 부모 Server Component는 변경된 Search Params를 바탕으로 라우트 핸들러에서 서버에 요청을 하고 필요한 데이터를 Server Component로 받아옵니다 . (부모 RSC는 캐싱을 하지 않게 구현되어있습니다.) 3. 받아온 데이터를 가공 후 자식 Client 컴포넌트에 내려주면, 4. props를 받은 자식 Client 컴포넌트에서 보여주는 방식으로 진행하고 있습니다. 위 과정에서 에러가 발생하는 것은 아니고 정상적으로 잘 동작하고 있습니다. 다만 브라우저 devtool의 Network 탭을 확인하는데 의문점이 있어서 질문을 드립니다. RSC에서 요청을 하면 _rsc 페이로드로 데이터를 받아오는 걸로 알고 있습니다. 분명 _rsc로 요청이 가고 정상적으로 네트워크탭의 preview에 RSC 페이로드가 찍히는가하면 정상적으로 요청이가고 페이지를 확인했을 땐 정상적으로 패칭과 렌더링까지 완료되었는데, 네트워크에서 preview에는 "no data found for resource with given identifier"로 나옵니다. 결론은 패칭과 렌더링은 정상적으로 동작하지만 네트워크탭의 preview와 response가 나올 때도 있고 안 나올 때도 있어서, 명확한 기준이 있는지 궁금해서 질문을 올립니다.

React 컴포넌트 안 or 밖에서 변수 선언-할당하는 것의 차이가 뭔가요?

삽입한 코드는 그냥 위치 설명하기 위한 것이고, 만약에 복잡한 계산식의 결과나, 긴 함수같은 것을 컴포넌트 안에서, 밖에서 선언했을 때의 차이가 명확히 뭔가요..?? (1) 컴포넌트의 state나 props가 바뀔 때마다 해당 컴포넌트가 리렌더링 되면 컴포넌트 내에서 선언-할당한 변수는 재선언-재할당 되나요? 그래서 이 불필요한 재선언-재할당을 막기 위해서 useCallback을 쓰는 건가요..? (2) 아니면 만약 함수의 내용이 state나 props를 사용해서 최신값을 참조해 사용해야 할 경우에 의존성 배열에 이를 넣어서 useCallback을 사용하는 것인지... usecallback의 명확한 목적도 헷갈립니다. (3) 또, 만약 함수 내용이 바뀔 일이 없고 state나 props 값도 사용하지 않으면, 컴포넌트 바깥에서 선언-할당하는 게 좋은 건가요? 성능적인 측면에서 뭐가 좋은 건 지 알려주시면 감사하겠습니다..!

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

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

1번과 2번 중 어떤게 더 유연한 컴포넌트 설계 방법일까요?

1번 코드와 2번 코드 중 상황 대처에 유연하고 처음 본 사람조차 쉽게 사용할 수 있을까요? 1번 코드의 경우 컴포넌트 내부에서 UI에서 나타내야하는 값을 로직을 수행 후 사용하는 개념이고 2번 코드의 경우 부모 컴포넌트에서 UI에서 나타내야하는 값을 로직을 수행 후 Props로 넘겨 자식 컴포넌트는 부모에게 받은 값을 그대로 보여주기만 하는 개념입니다.

Textfield 공통컴포넌트 설계질문

현재 Textfield를 위한 공통 컴포넌트를 설계하고 있습니다. Textfield에서 maxlength와 현재 value의 갯수를 보여주는 기능과, react-hook-form을 사용할수 있으며, 아이콘(버튼)을 클릭하면 특정 이벤트가 수행되는등 여러가지 기능을 아울러 수행하여 어디든 사용할수 있도록 하고싶습니다. 설계하면서 고민이 드는것이 있는데요. 저는 이모든것들을 props로 제어하려 합니다. 이유는 다음과 같은데요! 합성컴포넌트로 설계할경우 아이콘, 버튼의 갯수가 늘어나거나 위치가 변경됐을때 변화에 유연하겠지만 Textfield와 같은 공통컴포넌트의경우 기능, 디자인이 잘 변화하지 않기때문에 이런 결정을 했습니다! 혹시 다른분들은 어떻게 설계하시고 계신가요? 또는 관련된 레포나 문서 추천해주시면 감사하겠습니다.

자식 컴포넌트 suspense 적용 질문 드립니다.

안녕하세요, 다름이 아니라 suspense컴포넌트를 사용하려는 중, 작은 문제가 있어 질문글을 올리게 되었습니다. 페이지 헤더가 있고 헤더의 부모래퍼 영역에서 모든 api호출이 일어나고 props drilling으로 자식 컴포넌트에 데이터를 적용합니다. 하지만 부모 영역은 헤더 전체이므로 스켈레톤 처리가 어렵습니다. 단, 자식 영역은 데이터가 로드 될 때 까지 스켈레톤 처리를 하고싶은데, 이 때 suspense를 어떻게 하면 적용할 수 있는지 궁금합니다. 현재는 react-query를 사용하여 isLoading 변수를 받아 해당 변수에 따라 명령형으로 스켈레톤 처리를 진행하고있습니다.

첫 취업에대한 고민

4년제 내년2월 졸업예정인 컴퓨터공학과 학생입니다. 제가 프론트앤드개발자를 준비하다가 서류 이것저것 넣다가 어느 한곳이 최종합격이 되었습니다. 근데 그 회사가 250명, 매출액 500억 정도 규모의 중소로 연봉도 생각보다 높아서 회사 자체는 마음에 드는데 직무가 프론트개발보다는 웹 퍼블리셔의 직무여서 고민입니다. 완전한 퍼블리싱 직무였다면 저도 가지 않겠지만, 밑에 내용들 때문에 고민이 생겼습니다. 우선 사용언어: html,css,js,ts,react,vue 라고 공고에 써져있었고 저의 자소서는 프론트개발자로써의 자소서를 제출하였습니다. 또한 면접 질문도 react상태관리나 props drilling 등의 퍼블리셔와는 거리가 먼 질문을 하였습니다. 그리고 팀장분께 정확한 업무를 물어봤더니 지금은 퍼블리싱을 하고있고 백엔드팀에서 개발 부분은 다 하고있지만, 추후에 백앤드 팀에서 맡고있는 프론트개발 부분을 가져와 확실히 분리 하고 싶다고 들었습니다. 취업해서 퍼블리셔로 일하다가 프론트개발부분도 다루거나 나중에 공부를 더해서 이직을 생각하고있지만, 주변에서는 웹퍼블리셔로 시작하면 그것밖에 못하고 나중에 프론트개발자로 이직을 할때 인정도 안해준다는 말을 많이 들었습니다. 그래서 퍼블리셔의 업무만하면 고민도 없이 가지 않겠지만 위의 내용들 때문에 회사를 가야될지 그냥 국비를 듣거나 혼자 더 공부를해서 취준을 더 하는게 맞는건지 고민입니다. 취업이 그렇게 급한 상황은 아니고 그냥 제가 빨리 취업해서 돈 벌고 싶고 회사 자체는 마음에 들어서 고민입니다. 많은 조언 부탁드립니다!

Next.js의 dynamic import를 이용한 Ref 전달

현재 next.js 13버전과 toast ui calendar를 사용해서 프로젝트를 진행하고있습니다. toast ui calendar는 서버사이드에서는 렌더링이 되지 않기 때문에 dynamic 함수를 사용해서 import를 했습니다. dynamic 함수를 사용해서 import한 component에 ref를 넘기는 방법이 궁금합니다! https://careerly.co.kr/qnas/2078 위의 질문글을 보고 현재 아래 코드와 같이 작성을했는데 이렇게 작성을 하게된다면 결국 TuiCalendar라는 컴포넌트에는 ref={ref}, forwardRef를 사용해서 넘기는것이 아닌 forwardedRef라는 props로 ref를 넘기는형태가 되는건데 dynamic 함수를 사용해서 받아온 컴포넌트에 ref를 넘기는것은 이방법밖에 없을까요? 또한 "use client" import { useRef } from "react"; import Child from "./child"; export default function Parent (props : any) { const testRef = useRef(3) return ( <> <button onClick={() => console.log(testRef.current)}>버튼</button> <Child testRef={testRef} /> </> ) } 이것과 같이 ref를 그냥 props로 넘기는것과 ref + forwardRef 로넘기는 것의 차이점을 알고싶습니다!

부트캠프 최종발표 내용에 관해서

선생님들 안녕하세요. 부트캠프에서 셀프세차장 예약 앱을 주제로 약 두달여간의 개발을 진행했고, 3일 뒤에 최종발표만을 남겨두고 있습니다. 부트캠프 운영진 측에서 최종발표 내용으로 개발 주안점을 둔 부분을 주로 다뤘으면 좋겠다고 하셨습니다. 발표 내용을 미리 구성해봤는데, 선생님들께서 보시고 조언 좀 주시면 감사하겠습니다. 저희 팀 개발 스택은 다음과 같습니다. FE: React, Redux-thunk, React-query BE: Spring Boot, MySQL, Amazon S3 아래와 같이 발표 내용을 구성해 봤습니다. 1. 프론트엔드 a. 아토믹 패턴의 활용 - 기획단계에서부터 모든 컴포넌트들을 미리 설계해놓고 atom, molecule등의 레벨로 미리 나눠놨다. 덕분에 개발을 빠르게 진행할 수 있었고, 유저들에게 일관된 인터페이스를 제공한다. b. 예외처리 - 유저들에게 보다 친절한 에러를 제공하기 위해 백엔드와 협의하여 세부 에러코드들을 정의했다. 각 컴포넌트들을 에러 바운더리로 감싸 GET 요청이 실패한 경우에는 Fallback UI로 화면을 덮어줬다. 그리고 각 API들의 onError 콜백을 부여하여 Mutation 요청이 실패한 경우에는 alert로 알려준다. c. 상태관리 - props drilling 현상을 방지하기 위해 redux-thunk를 사용해 세차장 정보를 불러올 때마다 세차장 정보를 전역 상태로 관리하여 자식 컴포넌트로 넘겨주게 구성했다. 2. 백엔드 a. 예약 신뢰성 - 사용자가 요청한 예약이 운영 시간을 준수하고 중복 예약이 방지되도록 예약 검증을 철저히 하였다. b. 예외 처리 - 명확한 예외 처리 및 상태코드 할당 c. 권한 - 역할 기반 권한 관리, 사용자 인증 및 JWT 토큰 처리 여기까지입니다. 내용을 잘 구성했는지 모르겠습니다. 제가 경험해본 프로젝트 중 가장 규모가 큰지라 발표 내용이 부족하진 않은지 걱정이 많이 됩니다. 발표 평가위원이 주로 개발자라고 하셔서, 개발자의 시선으로 봤을 때 위 주제들이 어떠한지 고견을 듣고 싶습니다. 감사합니다.

리액트 책을 보면서 공부중인데 아래의 코드가 제대로 작동을 않합니다

import { useState } from "react"; type CounterProps = { initialValue: number; }; const Counter = (props: CounterProps) => { const { initialValue } = props; // 계정을 유지하는 하나의 상태를 useState()로 선언한다. 인수에는 초깃값을 지정한다. // count는 현재 상태, setCount는 상태를 업데이트하는 함수다。 const [count, setCount] = useState(initialValue); return ( <div> <p>Count: {count}</p> {/* setCount를 호출해서 상태를 업데이트한다 */} <button onClick={() => setCount(count - 1)}>-</button> <button onClick={() => setCount((prevCount) => prevCount + 1)}>+</button> </div> ); }; export default Counter; 책에 있는거 그대로 코딩 했는데 Property 'initialValue' is missing in type '{}' but required in type 'CounterProps' 이런 에러가 발생해요 왜 그런걸까요

(SSR 새로고침 문제)NextJS page에서 redux persist gate 설정하면 Client컴포넌트로 인식되는 문제

NextJS Pages Router에서 유저 데이터를 상태관리하기위해 redux를 사용했으나, 새로고침 시 데이터가 날라가는 문제를 해결하기 위해 persist gate를 사용했습니다. 하지만 redux persist gate를 사용하면 클라이언트 컴포넌트로 인지되는 문제가 있습니다. 궁금한 것 1) persist gate를 잘못써서 생긴 문제일까요? 아님 persist gate를 쓰면 안될까요? 2) 해결 방법으로 생각 해본 것은, "persist gate를 사용하지 않고 매 새로고침 시 저장되어있는 local storage에서 데이터를 새로 가져온다." 입니다. 3) ssr시 상태관리 새로고침 다른 방법으로 해결해본 경험 있으시면 아무렇게나 대답해주시면 감사하겠습니다!!! ----------------------------------------------- 문제의 코드 위치: https://github.com/bbookng/zippyziggy-v2/blob/main/frontend/zippy-ziggy/src/pages/_app.tsx 문제의 코드: import GlobalStyle from '@/styles/Global.style'; import useDarkMode from '@/hooks/useDarkMode'; import { media } from '@/styles/media'; import { darkTheme, lightTheme } from '@/styles/theme'; import type { AppProps } from 'next/app'; import { ThemeProvider, createGlobalStyle } from 'styled-components'; import normalize from 'styled-normalize'; import '@/styles/index.css'; import { QueryClient, QueryClientProvider } from '@tanstack/react-query'; import AppLayout from '@/layout/AppLayout'; import store, { persistor } from '@/core/store'; import { PersistGate } from 'redux-persist/integration/react'; import { Provider } from 'react-redux'; import { ReactQueryDevtools } from '@tanstack/react-query-devtools'; import 'toastify-js/src/toastify.css'; import { ToastContainer } from 'react-toastify'; import 'react-toastify/dist/ReactToastify.css'; import DefaultHead from '@/components/Head/DefaultHead'; import Construction from './construction'; const queryClient = new QueryClient({ defaultOptions: { queries: { refetchOnWindowFocus: false, // default: true }, }, }); function App({ Component, pageProps }: AppProps) { const { colorTheme, toggleTheme } = useDarkMode(); return ( <Provider store={store}> <PersistGate persistor={persistor}> <QueryClientProvider client={queryClient}> <ThemeProvider theme={colorTheme === 'dark' ? darkTheme : lightTheme}> <AppLayout toggleTheme={toggleTheme}> <Component {...pageProps} /> ... </AppLayout> </ThemeProvider> <ReactQueryDevtools initialIsOpen={false} /> </QueryClientProvider> </PersistGate> </Provider> ); } export default App;

Next.js(13.4.0) 모든 페이지에서 토큰 유/무 판단하기

현재 signup, signin, home, save, mypage 총 5개의 페이지가 있습니다. home, save, mypage에서 refresh-token의 존재 유/무에 따라서 signin 경로로 redirect 시키려고 합니다. 로그인을 하면 localStorage에 access-token 저장, browser cookie에 refresh-token이 저장됩니다. 로그인 후에 임의로 refresh-token 값을 지웠을 때, signin 경로로 redirect 시켜주기 위해 각 페이지에서 getServerSideProps를 사용하여 refresh-token의 존재 유/무를 판단하여 redirect를 시켜주고 있습니다. 현 상황처럼 각 페이지에서 인증을 처리하는 것이 아닌 모든 페이지에서 공통으로 인증을 처리하는 방법이 있는지 궁금하여 질문드립니다.