다들 좋은 아이디어 있으신가요? 혹시 fragment colocation 을 적용하는데 생...
# 잡담
h
다들 좋은 아이디어 있으신가요? 혹시 fragment colocation 을 적용하는데 생소하거나 어려운 포인트가 있다면 무엇일까요?
t
패턴적으로 맞는건지는 모르겠지만… 로딩 처리가 컴포넌트 안에서 완전하게 되면 좋을거같다… 라는 생각은 하고 있어요 ㅋㅋ Relay는 useQuery에서만 로딩 처리가 가능하다보니… 이전에는 각 컴포넌트에서 loading 분기쳐서 스켈레톤 보여줬는데요. 그걸 useQuery 아래에서만 하려니까 스타일 코드가 좀 중복되는거 같아요.
Fragment 변경시마다 Codegen 없이 Prisma Client 처럼 스키마 변경때마다 한번 Codegen 돌려놓고 TypeScript로 뚝딱뚝딱 Fragment를 작성하고 싶다… 라는 생각도 있습니다 ㅋㅋ
h
Fragment 변경시마다 Codegen 없이 Prisma Client 처럼 스키마 변경때마다 한번 Codegen 돌려놓고 TypeScript로 뚝딱뚝딱 Fragment를 작성하고 싶다…
Reason Relay go brrrr…………. ㅋㅋㅋㅋ
Relay는 useQuery에서만 로딩 처리가 가능하다보니…
이거 어려운 주제라고 생각합니다. 사실 기존에야 구분할 수 있는 단위가 별로 엎어서 쿼리 렌더러를 많이 분할해서 쓰게 됐는데 preload, normal, deferred, lazy 앞으로 이런식으로 다 구분되서 더 머리아픈것도 사실 ㅋㅋㅋ
제가 지금 다루는 제품은 카드형 위젯을 써서, 각 카드마다로 쿼리 렌더러를 분할하고 있습니다.
👍 1
t
쿼리 렌더러가 많아지면, 네트워크 요청이 많아지지않나요? Relay에서 합쳐주나요?
h
아폴로 씁니다. 아폴로나 릴레이나 안합쳐주는 걸로 알고 있고 따로 debounce 같은걸 붙여서 배치로 처리할 수는 있습니다
그래서 제가 fragment 공격적으로 쓰기 어려웠던 이유를 뽑자면… 아폴로 클라이언트 버그 ㅎㅎ;
네트워크 요청이 많아지지않나요?
일단 cache-first 정책을 쓰긴 해서, 많이 커지진 않습니다.