🦋 Changeset detected

Latest commit: 294de56

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

This could work — I think it'd be unexpected to many people as you'd show the optimistic mutation right away and then the synced data would pop in right after — typically I think people would preload the collection before going to the route & allowing optimistic mutations.

I think you're use case is you only create the collection when someone does a mutation and you know in this case it's empty? Could you just preload that empty creation when you enter the route?

I think it'd be unexpected to many people as you'd show the optimistic mutation right away and then the synced data would pop in right after — typically I think people would preload the collection before going to the route & allowing optimistic mutations

Yeah I think having collection loaded on screen before rendering ui that does optimistic inserts etc is def the typical use case. But the change here shouldn't really affect that case right? As far as I can tell, this change omostlynly affects folks that are optimistically inserting before sync is started - and in this case the expectation (at least my expectation hah) is that the optimistically inserted data is immediately available.

I think you're use case is you only create the collection when someone does a mutation and you know in this case it's empty? Could you just preload that empty creation when you enter the route?

Our use case is that we create a new shape (collection) per chat thread. So the user is on the home screen:

1. types something into the chat box & presses enter. this runs a tanstack db transaction that:
   a. optimistically inserts a thread record with id thread_xyz into the threads collection (there is only one of this collection - it's global)
   b. creates a new messages collection for thread thread_xyz, and optimistically inserts the user's message into it
2. immediately navigates to the route for the thread, e.g. /chat/thread_xyz
3. the thread screen renders a messages react component that creates a live query on that newly created messages collection. this live query kicks off the syncing

const messagesCollection = messageCollectionForThread('thread_xyz');

const { data, isReady } = useLiveQuery(
  q => q.from({ m: messagesCollection }).orderBy(({ m }) => m.createdAt, 'desc')
);

We're doing all of this in order to partition the messages queries, rather than always fetching lifetime history of all messages across all threads.

I thought that this was the recommended way to partition data atm, but I'm totally open to alternative approaches.

There was another use case that came up recently where you wouldn't want to wait for sync. When you have a left join and you don't want to block the initial render on the second collection loading.

Both and that and what you're doing feel like an opt in thing though as it's a bit surprising and perhaps unwanted otherwise.

Fair enough! Should I put it behind a flag somewhere, or what do you suggest? Maybe on useLiveQuery and similar fns?

as it's a bit surprising and perhaps unwanted otherwise

What typical situations would hit this new condition? Wouldn't the user have to

a) render a page with a live query or otherwise start sync for a collection
b) instead of rendering loading ui or similar, render ui elements/buttons/forms that optimistically insert into said collection when used
c) before sync is completed, end user uses those buttons / forms

Or something along those lines? Just trying to get a sense of how likely it is for folks to run into this use case when they are not intentionally trying to optimistically insert before sync.