search

Usic-Room / fe

0 stars 0 forks source link

Feat: Search Genre Recommend Page(w/o searchParameter page) #40

Closed yeomin4242 closed 1 week ago

yeomin4242 commented 1 week ago

️⃣연관된 이슈

28

ex) #이슈번호, #이슈번호

📝작업 내용

이번 PR에서 작업한 내용을 간략히 설명해주세요(이미지 첨부 가능)

스크린샷 (선택)

https://github.com/user-attachments/assets/1efedcb6-8454-42f2-9b83-06f7a499a1e7

https://github.com/user-attachments/assets/870020bc-f350-4be2-9182-ba334ba15bda

💬리뷰 요구사항(선택)

yeomin4242 commented 1 week ago

개인적으로 상태관리 툴을 사용한 이유는 두 가지가 있습니다. 1. 최대한 Link관련한 컴포넌트는 SSR로 두고 싶었기 때문

  1. Props Drill을 피하기 위해서 => 결합도 낮추기

그리고 zustand를 사용한 이유는 zustand가 redux랑 비슷하지만 store관리에 용이함에 있습니다. Jotai는 recoil과 비슷한데 atomic하게 분리된 상황에서 유리하다는 글을 봤는데 저희 프로젝트 상황과 조금 다른 거 같아서 zustand를 사용했습니다. 하지만 필요시 변경해도됩니다!

mixsung commented 1 week ago
  1. 최대한 Link관련한 컴포넌트는 SSR로 두고 싶었기 때문 부분을 제가 이해를 못했는데 왜 SSR로 두고 싶은지 알 수 있을까요? 저희는 아직 서버가 없으니 관련 코드는 없고, Zustand의 중앙집중식 상태관리로 CSR과 SSR을 분리해서 관리하겠다. 일까요???

p.s Next.js 지식 부족함 유의, 코멘트만 좀 열어두고 곧 pr 승인하겠습니다

yeomin4242 commented 1 week ago

Link태그로 페이지 이동하는 방식을 사용하는 컴포넌트를 Server Component에 두고 hook을 사용해서 router로 이동하는 방식을 client Component에 두고 싶다는 얘기였습니다!

next를 쓰는 입장에서 최대한 SEO를 생각해서 페이지이동은 Link태그로 처리하자! 그리고 Server Component화 시키자! 라는 생각으로 그렇게 처리했습니다!

오잉 근데 searchBar 컴포넌트를 CSR로 해버렸네요ㅋㅋㅋㅋ 말이랑 행동이랑 달라버렸네

yeomin4242 commented 1 week ago

그리고 이건 회의때 말씀드릴려고 했는데 zustand는 CSR관련해서 클라이언트 상태관리하는 측면으로 사용하고 SWR이나 react-query를 이용해서 server data fetching 및 caching을 다루면 좋을 것 같아요

참고한 자료

https://www.frontoverflow.com/magazine/6

https://mygumi.tistory.com/396

yeomin4242 commented 1 week ago

저도 next 잘 몰라서 시행착오 겪는 중이라서 그렇습니다 뭐가 좋은지 확인하는 과정인거 같아요ㅋㅋㅋㅋ...

yeomin4242 commented 1 week ago

제가 한말이 너무 정신없어서 다시 정리하면 최초엔 "최대한 Link 태그는 SSR로 보내자!"로 생각했습니다.

원래 "SearchBar"에서현재 url을 확인하는 구조는 page에서 "getServerSideProps"를 이용해서 현재의 위치를 파악해서 Layout에서 그것을 받아서 사용하는 방식으로 하려고 했습니다.

하지만 해당 컴포넌트가 layout.tsx에서 사용함으로써, page.tsx에서 부모 레이어로 올라가는 (맞는 표현인지 모르겠으나, 하위의 정보를 상위에서 쓴 단 느낌을 주고 싶었습니다) 상황에서 중복 코드 작성을 회피하고자 상태관리 툴을 고려했습니다! (nested한 구조일 경우 Layout에 따라서 또 조치를 해줘야 될 것 같다고 생각했기 때문)

근데 next 13 이후 page router -> app router가 되면서 getServerSideProps를 사용하는 방식이 사실상 없어지게 되면서 다른 방법을 찾아야되겠다고 생각했습니다.

그래서 위 경우엔 당장의 해결을 위해 usePathname()을 사용하는 CSR 방식으로 가게됐습니다. 제가 순간 헷갈려서 잘못 말씀드린거 같네요 죄송합니다...

어쨋든 제 생각엔 추후에 다른 방법을 통해서라도 정적으로 결정될 수 있는 상황에서는 최대한 SSR로 처리하는 방향으로 진행하는게 맞다고 생각합니다. (사용자의 입력값을 바탕으로 이동되야 하는 페이지가 결정되는 것 아니라면)

mixsung commented 1 week ago

저도 배우는 중이라서 질문이 많았습니다.. navigation할 때 최대한 Link를 사용하는 것은 정말 맞는 것 같구요. app router를 적용했기때문에 다른 page들은 사용자 상호작용이 없다면 page에서 SSR을 쓰면 되는데 검색은 쿼리에 따라 동적 라우팅이 되어서 예외상황이 되는 것 같아요. 현재 제 생각은 검색 페이지는 CSR로 가야하지 않나 싶습니다 (검색 페이지 컴포넌트 중 SSR이 있을 수 있음).

설명 중에 "하위의 정보를 상위에서 쓴 단 느낌"은 상위에서 정보를 갖고 있고 (+관리) 하위에서 그 정보를 받고 쓰는 걸로 가야(top-down) 나중에 꼬이지 않고 이해하기 편하지 않을까 싶습니다! 물론 말씀하신 내용도 이해했습니다. 고민 많이 하신 것 같아요. 고생하셨어요!