In all places where there is an on-chain interaction, i.e. extrinsic, currently, the experience for the user is blocked after the signing step has been completed, and the user has to wait until
the extrinsic is finalized, which takes +6s,
the backend has seen this block
the backend has processed this block.
Only after this last step is completed is there some sort of confirmation or success feedback, which I think in some cases my even require a confirmation or closing a window from the user. This is quite bad and even nerve-wracking experience, and it's not clear that we really need this.
Proposal
Whenever an extrinsic is sent off, some sort of client side optimistic UI can immediately be shown, and the user is free to keep navigating. The optimistic UI has to be a bit sophisticated, as it should not immediately allow the user to issue some new contingent action, i.e. an action who's feasibility is impacted by the outcome of an existing action which is not yet completed. For example, if you publish a new video, then the optimistic UI needs a sort of intermediate state where you cannot immediately delete it for example, as that would fail. I don't know how many cases like this there are, and it won't be obvious what is important to block. For example, should you block even opening the client side editing flow for a video instantly after it has been published? At any rate, for some - or possibly all actions, it may be worth showing some sort of progress indicator or something, ine the form of a flexible snackbar. This allows a long-lived representation of eahc action, which can help a user be alerted that some prior actioin failed. I don't know how important this really is, whether it is worth doing for all actions, or any actions, or at all in v1. A case by case analysis is needed here. It seems like a reasonably safe bet to. There is a second issue around dealing with multiple non-finalized or not-included(in block) transactions. They could be in the same browser window, in which case you need to have multiple of them represented in some way asynch, or they oculd be in distinct browser windows, in which case the app will have no awareness of this. The issue is if the failure or success of one transaction causes the failure of a later one. There is also the issue delay, perhaps one transaction gets stuck or lost, while a later one goes through, but hten has wrong nonce. It may be that we shuold jsut block this entirely, you have to wait for one action to fully complete before doing another on-chain action. This would solve the problem in one browser sesssion at least. So yeah, this i a hairy topic. It is so hairy that I wonder if Im just missing something basic about a standard approach to this, but not sure.
This cannot in principle be prevented, as the user may do things from distinct tabs, in which case the only solution is a backend to coordinate all user sessions, this would however be way more work, for perhaps not a lot of extra benefit.
Note: when we get server-side transaction broadcasting support in Orion, then these sort of progress indicators would work well cross device/tab/app also, but initially they won't.
KubaMikolajczyk
commented
1 year ago
Background
In all places where there is an on-chain interaction, i.e. extrinsic, currently, the experience for the user is blocked after the signing step has been completed, and the user has to wait until
Only after this last step is completed is there some sort of confirmation or success feedback, which I think in some cases my even require a confirmation or closing a window from the user. This is quite bad and even nerve-wracking experience, and it's not clear that we really need this.
Proposal
Whenever an extrinsic is sent off, some sort of client side optimistic UI can immediately be shown, and the user is free to keep navigating. The optimistic UI has to be a bit sophisticated, as it should not immediately allow the user to issue some new contingent action, i.e. an action who's feasibility is impacted by the outcome of an existing action which is not yet completed. For example, if you publish a new video, then the optimistic UI needs a sort of intermediate state where you cannot immediately delete it for example, as that would fail. I don't know how many cases like this there are, and it won't be obvious what is important to block. For example, should you block even opening the client side editing flow for a video instantly after it has been published? At any rate, for some - or possibly all actions, it may be worth showing some sort of progress indicator or something, ine the form of a flexible snackbar. This allows a long-lived representation of eahc action, which can help a user be alerted that some prior actioin failed. I don't know how important this really is, whether it is worth doing for all actions, or any actions, or at all in v1. A case by case analysis is needed here. It seems like a reasonably safe bet to. There is a second issue around dealing with multiple non-finalized or not-included(in block) transactions. They could be in the same browser window, in which case you need to have multiple of them represented in some way asynch, or they oculd be in distinct browser windows, in which case the app will have no awareness of this. The issue is if the failure or success of one transaction causes the failure of a later one. There is also the issue delay, perhaps one transaction gets stuck or lost, while a later one goes through, but hten has wrong nonce. It may be that we shuold jsut block this entirely, you have to wait for one action to fully complete before doing another on-chain action. This would solve the problem in one browser sesssion at least. So yeah, this i a hairy topic. It is so hairy that I wonder if Im just missing something basic about a standard approach to this, but not sure.
This cannot in principle be prevented, as the user may do things from distinct tabs, in which case the only solution is a backend to coordinate all user sessions, this would however be way more work, for perhaps not a lot of extra benefit.
Note: when we get server-side transaction broadcasting support in Orion, then these sort of progress indicators would work well cross device/tab/app also, but initially they won't.