인프런 커뮤니티 질문&답변
작성한 질문수
게시판 리스트 작성할 때 use client를 어디서부터 붙여야할지 모르겠어요
작성
·
44
0
<리스트>
<레코드1/>
<레코드2/>
</리스트>
일 경우…
리스트단에서 use client로 한 후 zustand에서 리스트 자체를 통으로 관리해야하는가?
각각의 레코드에 use client를 한 후 데이터를 받으면 zustand에 리스트를 만들어 레코드별로 hash(Map)으로 등록해 관리해야하는가?
레코드에는 좋아요, 조회수 등이 표시됨.
제 생각은
1번은 SEO가 중요한건 각각 레코드 (상세페이지) 이므로 zustand에서 통으로 넣어 관리하면 되니 구현 및 데이터 신뢰도에서는 나아보이는데 하나바뀌면 전부 렌더링되니까 애매한거같고
2번은 서버에서 모두 다 가져와서 초기속도는 빠르고 seo에 좋으나 zustand에 통으로 못넣고 데이터 자체를 내가 직접관리하는 구조라 구현 및 데이터 신뢰 측면에서는 골치아플거같은데…
무엇이 일반적인 구현방식인지 모르겠습니다.
도와주세요 ㅠㅠ
답변 1
0
답변이 조금 늦었네요..!
리스트 데이터를 클라이언트 상태로 어떻게 관리할지 고민할 때, 저도 같은 질문을 자주 하게 되어요. 특히 좋아요나 조회수처럼 계속 바뀌는 값이 들어간다면, 구조 설계에서 선택지가 애매하기도 해요.
결론부터 말하자면, 리스트 전체를 통으로 관리하는 방식보다는, 각 레코드를 저장하고 개별 상태로 구독하는 방식이 가장 현실적이고 일반적인 선택인 것 같아요.
그 이유는 다음과 같아요.
먼저, 리스트 단위로 zustand에 통째로 저장하는 방식은 구현이 단순하다는 장점이 있어요. 초기 데이터 신뢰성도 높고, 서버에서 한번에 가져오기 때문에 깔끔하죠. 하지만 이 방식은 말씀주신 것처럼 한 레코드의 좋아요 수만 바뀌어도 전체 리스트가 다시 렌더링되기 때문에 성능에서 손해를 봅니다. 동적 상호작용이 많을수록 이 비용은 커져요.
반면, 각 레코드를 Map 형태로 분리해 저장하면 레코드 단위로만 렌더링이 발생해요. 좋아요가 눌리거나 조회수가 늘어나더라도 해당 레코드만 변경되고, 나머지는 그대로 유지되어요. SSR로 리스트 전체를 내려준 뒤 클라이언트에서는 필요한 레코드만 다시 fetch하거나 상태를 갱신하면 되기 때문에, 초기 속도와 동적 업데이트 사이의 균형도 잡을 수 있어요.('use client' 가 되는 것과 SSR 여부는 별개여서요. 강의의 렌더링 파트를 보시면 조금 더 확실해지실 것 같아요 🙂 )
조금 번거롭긴 하지만 결국 이 방식이 유지보수성과 성능, 유연성을 동시에 확보할 수 있는 구조인것 같아요. 실무에서 React 앱을 설계할 때도 이 방식을 주로 했던 것 같아서요.
초기 데이터는 서버에서 리스트 형태로 내려받되, 클라이언트 상태에서는 Map<id, Record> 형태로 변환해 저장하고, 각각의 레코드를 zustand로 구독하는 구조를 추천해요. 그나마 적절한 타협점 인것 같아서요.