2.0.0-rc.0 createOptimisticStore works inconsistently/unintuitively

[DominicDolan]

Describe the bug

I'm not sure if this is a bug or if my understanding of createOptimistic/action is flawed but sometimes I have a hard time understanding how these work together. If it's not a bug then I find it fairly unintuitive.

I created a stackblitz example here. In it there are 2 versions of a todo example with a simulated backend. The first one uses createOptimisticStore as the way to store the todos, the second one just uses createStore instead.

In the optimistic example a lot of it works the way I would expect. You can add or remove todos and the updates show up straight away. In the store example there is a pause while it waits for the backend work to complete.

However, in the store example it behaves in an optimistic way for updating todos. Marking a todo as done or updating it's name shows up straight away, it doesn't wait. I don't really understand what I'm doing differently between adding/removing vs updating.

The second thing that I find more confusing is that in the optimistic example, clicking the save button on a todo after editing it causes it to wait, setIsEditing(false) doesn't resolve until the transition is finished. While in the store example this doesn't happen. Which seems reversed to me, why is the optimistic version waiting? Also, the isEditing is just an ordinary signal, why is its behaviour tied to whether I use a store or an optimistic store?

Your Example Website or App

https://stackblitz.com/edit/vitejs-vite-faxvqtln?file=src%2FTodo.tsx

Steps to Reproduce the Bug or Issue

1. Go to https://stackblitz.com/edit/vitejs-vite-faxvqtln
2. Add a todo
3. Edit the todo's name
4. Save the todo.

There is a wait time before isEditing() returns false again

5. Click on "Store" at the top
6. Add a todo
7. Edit the todo's name
8. Click save

There is no wait time for isEditing() to return false again

Expected behavior

.

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

No response

[brenelz]

Marking a todo as done or updating it's name shows up straight away, it doesn't wait.

This is because you don't have a sleep on the toggle,updateName endpoints so it happens instantly

[DominicDolan]

Ah, sorry. I missed that. And yes it does work more as I would expect it to if that is fixed.

However, I'm still unsure about the isEditing() point

[brenelz]

So I admit it is a bit confusing, but I think its working as intended. The difference you're seeing is that refresh(todos) doesn't hold a plain store's transaction open, but it does hold an optimistic one

[ryansolid]

Yeah I don't think this is a bug. But we need to do a lot better on explaining/documenting this.

I don't think we have to resort into transition isolating APIs.. we have flush but that is agressive and breaks composition.. setTimeout is arguably better if these things are detached anyway.

But you can also handle this derived.

The same pattern for the save button. Your Button does exactly this with isBusy. Keep isEditing as the persistent truth, add an optimistic in-flight flag, and derive the view:

const [isEditing, setIsEditing] = createSignal(false);   // persistent: user intent
const [isSaving, setIsSaving] = createOptimistic(false); // lives only as long as the transaction
const showForm = () => isEditing() && !isSaving();
function onSaveClicked() {
  setIsSaving(true);      // optimistic: visible immediately
  setIsEditing(false);    // rides the transaction, commits at settle
  props.onUpdate(editValue());
}

Maybe not the most intuitive?

[DominicDolan]

Yeah, it does feel like there is quite a bit of learning to do for solid developers with this. I would worry about more complex cases being hard to debug. Like if you decided to change from createStore to createOptimisticStore and then something breaks somewhere else. And it's because a signal was set as part of the same transition as a refresh. It might be hard to track down why.

I also realised you can use setTimeout to opt out of the transition, I don't know if that's something you would recommend:

const [isEditing, setIsEditing] = createSignal(false); 
function onSaveClicked() {
  setTimeout(() => {
    setIsEditing(false); 
  })
  props.onUpdate(editValue());
}

[ryansolid]

Yeah to be fair this is a property of these async models in general. Like React's Transition model has similar issue. It ends up being infectious. They want component authors to wrap like all their button clicks in transitions. Same with Svelte's upcoming one.

I think the move from sync to async is when these sort of createStore -> createOptimisticStore moments happen, because it signals a move in the authorative source of truth.. The async itself is what causes the holding behavior so regardless of the primitive you are forced into aligning to that. Like if someone has a bunch of distributed setStore calls all over the place changing to optimistic is going to be pretty breaking regardless bucause it is reverting behavior.

Admittedly this is why I've always favored the action approach in the sense of having named mutations. The the actual setters stay local. The read/write split of our primitives already lean towards this more than mutable APIs so the right foundation is there, but I'm not going pretend that this model is not pretty alien right now.

Regarding setTimeout that's what I meant in my response above. It's fine. I'd use it a bit sparingly. It does push the update on 2 different cycles but that is relatively cheap. I'd almost recommend it in many cases but its hard to call it the most general approach because it has the behavior implications.

Moving to a discussion.