배휘동
11/06/2021, 9:28 AMTony Won
Hyeseong Kim
11/06/2021, 5:42 PMTony Won
mutation 후 invalidate할 때 캐시를 잘 관리하는 게 쉽지 않았습니다.요거 정확한 시나리오가 궁금한데 혹시 알려주실수있을까요? 왠지 오해가 있을거같아서 자세히 설명드리고 싶습니다
배휘동
11/08/2021, 8:42 AMquery {
articles {
id
title
}
}
mutation UpdateArticleTitle($id: ID!, $title: String!) {
updateArticleTitle(input: { articleId: $id, title: $title }) {
article { // 아폴로 캐시의 articles에 해당 id 값의 title이 자동 업데이트됨
id
title
}
}
}
mutation RemoveArticle($id: ID!) {
removeArticle(input: { articleId: $id }) {
query { // mutation 응답에서 목록을 다시 불러옴
articles {
id
title
}
}
}
}
Hyeseong Kim
11/08/2021, 11:34 AMInfiniteQuery가 애초에 일반 쿼리와 구분되어 있어서 invalidate하면 기존 캐시에 있는 것들을 순차적으로 업데이트해주길래 편했습니다.네 이게 Pagination 이 대표적으로 데이터 그래프 모델링할 때 다루지 않고 클라이언트에서 추상화되어야 하는 순수 UI 로직이라서 그런데요. 말씀하신거처럼 유틸리티를 만들어서 대응하고 Apollo Client 에서는 주로 Type Policy 에서 정책을 재사용하는 식으로 다룹니다. 저 같은 경우는 전에 Apollo Client 2 쓸 때 요청 크게 나가는게 싫어서 Offset 맥락을 따로 관리했던 기억이 있네요.
배휘동
11/08/2021, 11:58 AMHyeseong Kim
11/08/2021, 12:18 PM배휘동
11/09/2021, 5:51 AMTony Won
mutation PageReviewsDeleteReviewMutation(
$reviewId: ID!
$connections: [ID!]!
) {
deleteReview(input: {
reviewId: $reviewId,
}) {
__typename
...on DeleteReviewOutput_Result {
result {
reviewEdge {
node {
id @deleteEdge(connections: $connections)
}
}
widget {
...ProfileReviews_widget
}
}
}
...on DeleteReviewOutput_WidgetNotFoundError {
widgetNotFoundError {
message
}
}
...on DeleteReviewOutput_ReviewNotFoundError {
reviewNotFoundError {
message
}
}
...on UnauthorizedError {
unauthorizedError {
message
}
}
...on UnknownError {
unknownError {
message
}
}
}
}
delete 할때는 이렇게 하구요 ㅎㅎ append, prepend할때는 마찬가지로 @appendEdge
@prependEdge
directive를 쓰면 relay가 자동으로 붙여줘요.배휘동
11/09/2021, 9:07 AMTony Won
다른 유저의 행위에 의해 목록의 구성이 바뀌었을 수 있음이건 해당 유저에게는 중요한 변경사항이 아닐수있어요. 유저가 "바라보는 세상"의 일들만 Consistency가 맞으면 됩니다 ㅎㅎ (그게 DB와 100% 싱크를 맞출수는 없어요. 만약에 그걸 원하시면 Subscription을...) 만약에 그정도로 중요한 실시간 변경사항이면 구현하셨던것처럼 refetch나 Subscription으로 받는게 맞을거같네요. 근데 이건 Normalize된 캐시라서 더 어려운 문제는 아닐거같아요.
아이템을 추가했을 때는, mutation 결과를 어디에 붙여넣을지 클라이언트가 정렬 순서를 정확히 알고 있어야 함넵 이건 맞습니다. 다만, 정렬 순서랑 관계없이, 일반적으로 유저가 작성한 콘텐츠는은 맨 위 (ex: 페이스북 피드) 또는 맨 아래 (ex: 채팅) 에 가는게 일반적입니다. 페이스북 피드는 시간 순서가 아니지만 유저가 글을 쓰면 맨 위로 올려주죠. 정렬보다는 유저의 탐험 경험과 연관이 더 많을거같아요. 리스트 중간에 추가한다던지 하는 경우는 저는 여태까지 경험을 못해봤네요;; 지금 당장 떠오르는 Use case는 상단 고정 게시글이 있다고 했을때 그 밑에 꼽는건데요. 위쪽 고정 게시물은 따로 처리하고, 그 아래부터 connection으로 간주하면 마찬가지로 쉽게 구현할 수 있을거같아요.
배휘동
11/10/2021, 10:01 AM유저가 "바라보는 세상"의 일들만 Consistency가 맞으면 됩니다이 말씀이 잘 와닿네요. "정렬보다는 유저의 탐험 경험" 이라는 말씀과도 잘 연결이 되는군요.