[최권진] sprint 9 #163
[최권진] sprint 9 #163
Conversation
dongqui
left a comment
dongqui
left a comment
There was a problem hiding this comment.
권진님 이번 미션도 고생 많으셨습니다!
이제는 컴포넌트, 훅으로 페이지 하나 정도는 뚝딱뚝딱 만드시는군요 🤣
심화 요구사항에 "next의 data prefetch 기능을 사용해봅니다." 라고 되어있는데, 베스트 게시글은 사용자 화면에 따라 fetch하는 값이 달라야해서 next의 data prefetch 기능을 사용이 불가능하고, 일반 게시글 또한 정렬에 따라 게시글이 바뀌어서 next의 data prefetch 기능을 사용이 불가능 한 것 아닌가요?! next의 data prefetch 기능을 사용 할 수 있는 부분은 "베스트 게시글 (텍스트)", "게시글 (텍스트)" , (글쓰기 (텍스트)" 이 부분만 해당하는게 맞을까요?
->
화면 크기에 따라 데이터 수를 정하는 것은 좀 애매한 부분이 있기는 합니다. 다만 next로 들어오는 request header user-agent 같은 값들을 확인해서 모바일인지, 데스크탑인지 정도 확인할 수는 있어요! (이 경우 화면 크기가 정확하지는 않겠죠 ㅎ)
화면 크기가 조금 애매한 거 말고는 해당 페이지는 data fetch가 가능합니다!
두 가지가 방법이 있는데, 첫 번째는 쿼리스트링을 활용합니다.
처음 접속시에 next에서 데이터 패치 후 SSR을 진행합니다. 이후 정렬, 페이지를 바꾸면 쿼리스트링을 수정합니다. 쿼리스트링이 수정되면 getServerSideProps, 혹은 getStaticProps 함수가 실행되고 페이지를 생성하는 SSR을 진행하는 것이아니라 JSON 형태의 데이터만 내려보냅니다. next의 SSR은 첫 접속 한 번만 진행한다고 생각하시면 됩니다.
https://nextjs.org/docs/pages/building-your-application/data-fetching/get-server-side-props#behavior
두 번째는 초기 데이터만 next에서 fetch하고 이후 추가적으로 호출하거나 변경되는 데이터는 모두 클라이언트에서 처리하는 방법입니다. 권진님의 경우 무한 스크롤을 구현 하셨으니 두 번째 방법이 더 잘 맞겠죠 :) (다만 지금은 page api 문제로 복잡할 거 같네요)
그리고 구분해주셔야 할 것이 있는데, next의 data prefetch 기능을 사용 할 수 있는 부분은 "베스트 게시글 (텍스트)", "게시글 (텍스트)" , (글쓰기 (텍스트)" 이 부분만 해당하는게 맞을까요? 여기서 말씀 주신 영역은 데이터 패치가 필요 없죠..! 이미 next에서 SSR을 진행하고 있습니다.
There was a problem hiding this comment.
page 폴더 내에는 라우팅 관련된 파일만 있어야 합니다!
현재 들어있는 폴더, 파일들은 모두 페이지로 만들어집니다.
지금 http://localhost:3000/hooks/useFetchArticles 로 접속하면 404가 아니라 React에러가 발생하고 있죠..!
There was a problem hiding this comment.
There was a problem hiding this comment.
요구사항대로, 해당 페이지가 /boards 경로를 가지기 위해선 파일이 boards 폴더내에 존재 해야합니다!
| useEffect(() => { | ||
| if (!fetched) return; | ||
|
|
||
| if (fetched.list.length < pageSize) setHasMore(false); |
There was a problem hiding this comment.
아무래도 page 기반 api로 무한스크롤을 구현하다보니 복잡해지고 부차적으로 처리할 것들이 생긴 거 같습니다!
무한 스크롤은 어디부터 데이터를 보내줄지, 데이터가 더 있는지를 서버에서 정해줘야하기 때문에 cursor 기반의 api가 필요합니다.
그런데 피그마 디자인 시안이 애매하게 나왔네요.. 😠
실무였다면 디자인, 백엔드 둘 중 하나의 잘못으로 판단하고 미팅 소집했을 거 같습니다 🤣
| }, []); | ||
|
|
||
| /** | ||
| * 요구사항이 모바일 태블릿 pc 사용자에 따라서 데이터를 fetch하면 되어서 굳이 화면이 변경될 때마다 fetch를 해서 데이터를 새로 받아오지 않게 하려고 했어요. |
There was a problem hiding this comment.
useFetchBestArticle 훅에 대한 코드 작성 시 주석으로 해당 코드 구현 이유를 적었는데, 혹시 실무에서는 저와 같은 방식을 쓰는지, resize 이벤트를 통해 기기 넓이 별 fetch 개수를 변경하는지, 아니면 다른 방법을 사용하는지 궁금합니다.
->
정답은 없는 거 같아요! 타겟 디바이스가 명확한 서비스일 수도 있고, 데이터 양이 엄청 많은 경우도 있을 수 있고, 아니면 UI 자체가 자연스럽게 대응 가능한다던가...
서비스 성격에 따라 달라질 수 있을 거 같습니다만, 아무래도 resize에 따라 데이터를 가져오는 게 좀 더 안정적일 거 같기는 하네요 :) 저 같이 윈도우스냅을 자주 쓰는 유저들은 브라우저 사이즈가 잘 바뀌기 때문에 작은 화면에서 큰 화면으로 넘어갔을 때 부자연스러운 UI를 만날 수도 있을 거 같습니다 🤣
2 participants
요구사항
기본
심화
멘토에게