Lunie: Optimistic UI implementation

[okwme]

• [ ] Add in new layouts from https://github.com/cosmos/voyager/issues/1092

[NodeGuy]

Can this be moved to staking2?

[jbibla]

though i want to say yes, for the sake of "progress", i really think this is less to do with staking and more to do with the whole voyager ux. the principles discussed in #1092 apply to all the features and will elevate the ux for all areas of the app.

so no. i don't think so. but we can make it high priority and remove the staking label 😄

[faboweb]

@sabau let's come up with a technical design proposal for this problem

[jbibla]

this problem? https://github.com/cosmos/voyager/issues/1092#issuecomment-418142498

[faboweb]

Yes. I was talking about a technical proposal of how to have a proper process in code (not on the design level).

[sabau]

Love the idea, I tackled a similar problem years ago I will write down the solution we found and we can discuss it how to adapt/change/discard that :)

• The GUID part I really think is not relevant for this project, as we have a fixed structure and the user cannot modify how the UI looks like by adding or removing tabs, components etc.., We can probably just reference portions of our state

Real state

• User see everything in his natural color and opacity

Unconfirmed state / transactions

• Blocks are what I expect on certain part of my state to happen if my transaction succeed
• There are two possible blocks: newItems and deltas
• Every part of the state can be logically composed by blocks and Referenced by (GUID or similar) generic IDS not referring to any particular area, just generic IDS, the block describe where he will will have an impact

• at rendering time we show the Real state, for every component we know a GUID is present, so we simply check in our dictionary of the unconfirmed states / transactions if this component has a WIP, we choose to show the unconfirmed block (or the delta when needed)

  • example: I made a transaction, I will add 2 unconfirmend blocks:
  • The new transaction that still does not exists on my transactions list (corner case) we should show them on top?
  • The new Balance as Delta []
  • I do another transaction:
  • add another state to Delta () and build your balance by summing up all of them

  • add another new block as transaction and show it on top

  • If one fails and one succeed

    • both deltas disappear (we received the real confirmations, so our real state include already the most up to date information) the balance just go back to the original color
    • both transactions disappear from the stack of WIP blocks, if you are on the transaction page you should see some behaviour that fade out the failed one (maybe a red-ish disappear or just fading out and bye bye) and a different one that transition the succeded one to a normal transaction (can be green-ish animation or just removig the greyness should be enough)
• Everything that has a WIP must have an icon or a diffent grey-ish color to clearly differentiate from a final state or transaction (if I have a list of 3 items and only one is work in progress, it must be clear and easily identifiable the difference between the two)
• once the transaction is confirmed, if the user is actively watching a component that change state, we need a smooth transition, if he's not watching we can choose do just change or show notifications depending on the criticality of the block we want to change

[sabau]

we can do in simpler way:

• not everything needs to have this unfconfirmed state
• isolated states

Alternative approach:

• Just update the state as if succeeded
• then query for the next block

[jbibla]

closed in favour of #1849