Think of a way to handle async actions

There is multiple way to handle every action in stateful component in the app like the toggle.

First is to let the dev decide of the state of the component :

• There is a onPressed event (the component is pressed but there is no indication about the actual state of the component)
• a value property that decide of the state of the component (Switch ON/OFF)
• The dev can change the value outside of the onPressed event.
• The user will experience a delay between the click and the actual action done
• The component can have a loading state that will tell the user that the app is working.

Second is to let the system decide for the dev :

• The "real" state is on the client-side component
• The dev must sync the server-side data to the client-side component state
• There is a onChanged event (the component tell the dev the new value)
• There is NO value property. The dev cannot choose the state of the component apart of the initial state.
• The user have no delay on screen.

The third is a variant of the first but with an "optimistic" display :

• Still the onPressed/value system, the dev still have the control
• There is no loading state but the component will behave optimistically and react as if the dev actually change/toggle the state. (Toggle the switch)
• For most common case the user will not experience any lag nor loading state
• For less common case the user will experience a "rollback" if the dev decide not to update the state as expected.
• May in some case de-sync the server and client (if the server-side crash or race-condition on the same value)

I think the best choice is to allow the dev to decide between first and third case.

• First case for the default behavior as it will never de-sync.
• Thirst case on demand for each component as an optimisation for basic use case.

@taorepoara @jonas-martinez @shiipou what is your opinion ?

Start with the stateful component and toggle behavior described in the issue; no file, test, or entry point is named. First resolve which async and optimistic-state API should be supported with maintainers, then define the affected components and tests that would demonstrate the chosen behavior.