Optimistic Store Creation

[fwindolf]

I am developing an application where a resource was shared between multiple users (eventually).
It's actually quite similar to the todos within workspace example in the docs, if one of the deciding features was that you could create a new todo within a new workspace immediately.

As todos are added to a workspace, and shared between users, there would be one store per user, which determines membership to a workspace (so the application knows which workspaces to load), and one store per workspace with todos, so there is a unique source of truth for todos.
On creation of a new todo within a new workspace, the workspace store would have to be created which currenlty is a blocking operation, and therefore you don't get the instant reactivity on that store that makes livestore the great tool it is.

There is two options to compensate:
A) Store workspace metadata (name, etc.) in the user store for instant rendering. The concern is that this data becomes stale if someone edits the workspace. You'd have the same info in two places.
B) Show a spinner after navigating to the new workspace until the store is ready. This defeats the desired instant UX.

One real mitigation would be to use the same optimistic rendering on a store that physically doesn't exist yet, get immediate reactivity, and have the actual store creation happen in the background.

---

My opinion: For bigger/more complex apps, you don't get around having multiple stores. The division between user/access and objects seems to be the common pattern. When working with resources that are user managed AND that can be shared between users there is no (good imo) way around this division - and to me it feels like a good/natural separation of concerns.
Using cross-store backend worflows to enforce eventual consistency feels like a workaround, rather than a clean solution to the problem, as there is a clean solution available: Separate content from access. In the workspace example, there is an immutable id of the workspace that needs to exist in order to reference the workspace to determine user access. Using that to identify the workspace, access to the workspace, and finally the store is the obvious choice.
Now if store creation was instant, this wouldn't be a problem at all and the solution would just work as is. But it neglects the fact that creating databases and communicating with the server is not. A similar problem arises when creating a new object within a store, where livestore makes the choice to have optimistic reactivity, and compensate for problems that might occur after sync. Without any knowledge what would actually be necessary to pull it off, using the same optimistic approach for store creation would solve the whole problem, as we would get instant reactivity for UI, and could compensate later if the creation failed/is rejected.

I hope this was clear enough. See also the related discussion on discord: https://discord.com/channels/1154415661842452532/1450622479860105279

[IGassmann]

@fwindolf I want to make sure I understand your use case correctly. You mentioned:

one of the deciding features was that you could create a new todo within a new workspace immediately

and

On creation of a new todo within a new workspace, the workspace store would have to be created

Can you walk me through the specific user flow in your app? Is workspace creation a separate deliberate action (e.g., user clicks "New Workspace"), or does it happen implicitly as part of creating content (e.g., user creates a todo and selects "New Workspace" from a dropdown in the same form)?

I'm trying to understand why a two-step approach wouldn't work:

1. Create workspace (accept brief loading state once)
2. Add todos instantly (store now exists)

This would isolate the "one-time setup cost" to workspace creation, while keeping the frequent action (adding todos) instant. Is there something about your app's UX that requires these to be a single atomic action?

[fwindolf]

Yeah, so for the app I'm working on there is a marketplace for two types of users. One are resource owners, the others needs access to the resource - say something like a car and then all the paperwork associated with a car. As a user can own multiple cars, and the list of things that can happen to a car in terms of modifications, contracts, repairs, etc are quite long, and I want to have some access patterns baked into the data layout, I would say one store per car makes sense.

So the flow is:

• User visits their profile page (or is prompted in home screen when not having something set up)
• User fills a form to put all the info in for the car
• User hits the create button, and immediately sees the car in their profile

In the background we create the store, add the entry into the user store about the car belonging to the owner.
What's important is that the car isn't attached to the user in any ways, because theoretically ownership can be transferred and we don't want to lose all the paperwork associated with the car.

But maybe the solution to this is to just use a pre-created store based on a id that's created on form screen enter, and then just discard the store/id if the user cancels.

[IGassmann]

Thanks for the context! One store per car sounds like a sound data model from what I can gather. So to sum up, we have:

• Car store (source of truth for car data): Ownership events live here (e.g. v1.OwnershipTransferred, etc.). The car store tracks the full history of who owned it and when.
• User store (contains list of user's cars): A userCars table that lists car IDs the user currently has access to. This is duplicated data, but necessary so you know which car stores to load when the user logs in.

Making Car Creation Feel Instant

Your proposed solution:

But maybe the solution to this is to just use a pre-created store based on a id that's created on form screen enter, and then just discard the store/id if the user cancels.

I'd call this "eager provisioning". A few considerations on it:

• Timing: You'd need a fallback if the user submits before provisioning completes (brief loading state or disabled button). This can happen on a slow or flaky network.
• Cleanup: Need to garbage-collect abandoned stores when users enter the form but don't submit (TTL or periodic cleanup job).
• Offline: Doesn't work offline. provisioning requires the backend. If the user is offline when they enter the form, they're blocked.

Alternative Approaches

1. Accept a brief loading state. How often do users create a new car? If it's rare and/or usually happens a along-side a online-only user action (e.g. sign up), a loading spinner on creation might be acceptable. No extra complexity, no cleanup, less edge cases. You can revisit later if user feedback suggests it's a pain point.
2. Draft state in user store. Store the initial car data in the user store immediately on submit (instant and works offline), show the car in the UI with a subtle "setting up..." or "draft" indicator, then provision the car store in the background. Once ready, commit the real event there. Compared to "eager provisioning", this has the benefits of:

• Always instant: no racing against provisioning time
• Works offline: user store commit is local, car store gets provisioned when back online
• No abandoned store cleanup: you only provision after the user commits

However, you will need to handle the draft→real transition and implement/handle the car's "draft"/"setting up..." state.