FEATURE: Improve general error handling paths about fulcro

[awkay]

So, we've got dynamic queries, the history is improved, and I've just added ptransact!. The latter allows for manual sequential full-stack interactions that make error handling straightfoward for old-school interactions.

The automated stuff I'm aiming for with this ticket is going to be pretty interesting to implement. The fully-working history means that we can safely rewind UI to the point in history at which our last network interaction occurred. This means we can auto-retry on errors while the user is allowed to continue to work (possibly showing a "saving..." indicator in the UI somewhere. If the network stays gone too long, then we can rewind to the last-known-good spot, show them a dialog, and let them choose "retry some more, or restart from here"

[petterik]

Follow up. Your comments are quoted.

I also wonder about the limits of optimistic update on lag.

This is a scary thought indeed. But it hasn't been a problem for us yet.

Fulcro augmented Om Next by ensuring that tempids that appear in the network queue get rewritten on tempid remappings...so you can actually queue a create and update in sequence and have them work in complete optimistic mode.

Same here. We also update our mutations that are queued to get the correct id.

In the talk, the assumption is that your mutations might return something different from what you'd done optimistically. I think this is wrong.

We usually implement optimistic updates where we can fake what the correct result should be. E.g sending a chat message, it should show up in the chat. But I can recall times where we've done an optimistic mutation showing the user a "pending" result, that differs from the server's response and is replaced by it. There are other ways of implementing such behaviour though.

Regarding linear history. Our first attempt was to have a single history with no branches, but it got too hard for us when trying to do optimistic updates that had to be retracted or merged such that nothing changes when the response from the server matches the current state. You may have better ideas on how to implement it, but I found it very hard both to think about and to implement compared to the git-rebase version.

For some context, our first project was a budget web app where it was really nice to have optimistic updates. Now, we've released an e-commerce marketplace with live streaming (http://sulo.live) and it doesn't need as many optimistic updates. It's nice to have some times, like for the chat.

I agree with how you think mutation errors should be handled. I.e. auto-loop with back-off and rewind. We've got the auto-loop but not the rewind, but it sounds like a good idea!

[awkay]

The chat example is an interesting case. That is a case where you are direct-collaborating in a distributed system, but the problem there is "time" and "relativity". I think I'd implement that one without optimistic updates at all (you typing a message sends it to the server, and websocket pushes are always how things end up in your chat window). That way the server resolves "who spoke when". I guess you could do optimistic and use the server's timestamp with the "rebase" idea, and that is an example where that model is needed if you want to do it optimistically (though so is agreement on time).

I guess if you take the collaborative editing example of any kind (where optimistic updates are desired) then you have a much harder problem, and one that potentially makes kind of a mess. If we were both in offline-mode while editing the same line of text our interspersed edits would just as likely end up gibberish as anything useful.

[awkay]

The new work on Fulcro 2.0 will improve dynamic queries and history to make this scheme possible. Hoping to have it done by the end of November, if not sooner.

[awkay]

This last bit is really issue #49