feat: support filtering, sorting & pagination when loading CoValues#2946
feat: support filtering, sorting & pagination when loading CoValues#2946nrainhart wants to merge 59 commits into
Conversation
The goal is to store a single index-related reference in the CoValue's history
| private constructor( | ||
| init: { header: CoValueHeader } | { id: RawCoID }, | ||
| node: LocalNode, |
There was a problem hiding this comment.
We're never providing a header, so I removed that option
| private constructor( | ||
| init: { header: CoValueHeader } | { id: RawCoID }, | ||
| node: LocalNode, |
| subscription.branchOwnerId !== | ||
| options?.unstable_branch?.owner?.$jazz.id || | ||
| (subscription.subscription && | ||
| subscription.subscription.resolve !== resolveQuery) |
There was a problem hiding this comment.
question: why are we relying on useStructuralEquals vs calling structuralEquals here?
There was a problem hiding this comment.
This useLayoutEffect is re-subscribing to the context manager each time it runs, so I wanted to detect the change in the resolve query earlier. I see there's still an integration test failing due to an infinite render loop, so I need to look into this some more
| // Need all these checks because the migration can trigger new syncronous updates | ||
| if (queryFields.length > 0 && value !== "unavailable") { | ||
| this.requestCoListChildrenLoad(); | ||
| } |
There was a problem hiding this comment.
Is it ok for ths to run also on non-coList values?
There was a problem hiding this comment.
Heh, $where and $orderBy can only be used with CoLists that contain CoMaps right now. I'll work to extend it to CoLists with plain JSON objects as well
gdorsi
left a comment
There was a problem hiding this comment.
What happens when a value that doesn't match the filter criteria is updated?
Right now the subscription update will still be triggered. I'll modify this to prevent the update from happening if the query view didn't change. |
Description
We want to extend the resolve query API to allow filtering, sorting and paginating CoList elements:
This will provide a simpler way to perform these operations and pave the way for implementing indexes. For now, we're loading all the CoList elements and performing the filter/sort/pagination operations in memory, but longer term the goal is to use indexes to avoid fetching the CoList elements.
There are some pending things to do before merging this PR:
But this PR can already be reviewed.
Key design decisions
$wherefor filtering CoLists elements$eq,$ne,$gt,$gte,$lt,$lte$and,$or,$not$orderByfor sorting$limit&offsetfor paginationuseCoStateto re-create the subscription scope if the resolve query is updatedTests
Checklist