Add async-CustomInput support

[inamiy]

This PR is an experiment of asynchronously displaying CustomInput after cell tap.
Example demo can be found in SignUp screen.

This feature is needed when OptionPicker 's data is not ready yet and requires async fetch before CustomInput presentation.
It is triggered by state change and focusesOnFirstDisplay is set.

The implementation is complete, so please review and tell me this is the right way to go.
(Please don't review about example code. It will be deleted afterwards)

Changes

• ad713ac Added func customInputImmediately(when:input:)
• Added focusesOnFirstDisplay
• Allow CustomInputComponent.ComponentView to present FocusToolbar without back/forward buttons when it is not focus-eligible (due to asynchrony).

Screencast

TODO

• Organize example

[inamiy]

ad713ac
Simplified code to func customInputImmediately(when:input:).
Previous tweaks in func customInput is reverted.

[dmcrodrigues]

Do we really need to change CustomInputComponent to support this? Why can't we just return self when state is nil? At least I think this should be done the same way that we build boxes where sections and/or nodes are conditionally composed depending on a certain condition and here I think we could follow the same principle, if the state is nil it means there's no CustomInput so we don't need a CustomInputComponent but once that changes we can then build a CustomInputComponent to display that input.

I'm not sure if I'm missing some detail.

[inamiy]

state = nil doesn't mean we don't use customInput at all.
It's rather the same behavior as we already have: "Show customInput when user tapped"

On the contrary, when state exists, customInput shows immediately when re-rendered.
It also holds the same property "show customInput when user tapped" as well.

[inamiy]

Maybe I should rename method e.g. func customInput(immediatelyWhen:...) so that "immediately" belongs to state existence.

[dmcrodrigues]

state = nil doesn't mean we don't use customInput at all.
It's rather the same behavior as we already have: "Show customInput when user tapped"

I'm a bit confused, in your example you tap Gender and there's no input being presented, you display an activity indicator as accessory and after 1 sec. your state changes and then it shows the option picker, why do we need to have a custom input before the change of state?

[inamiy]

why do we need to have a custom input before the change of state

That's good question!
IIRC I tried the same approach by removing customInput only when loading.
But this caused Bento diffing animation for the entire "gender cell" that I wanted to avoid.
So, keeping customInput throughout the handling is (probably) required to avoid such animations.

[dmcrodrigues]

Oh yes it does that because we are swapping from one component to another one if we do that 😕

I don't see any way to avoid that animation but maybe @andersio has an idea.

[inamiy]

There could be some diffing optimization, but I think it's still OK to always keep customInput during loading.
It might still be able to tap though (which will be a bug), I can add isEnabled property to prevent that, so that we don't need to worry about removal animation of customInput.

[inamiy]

(For sure diffing optimization will be more nice, but we won't probably invest too much here)

[andersio]

#146 is meant to tackle that. But I'd be surprised that there is any deleting animation. It should be a subtle cross-fade.

[inamiy]

In PR party, @andersio came up with an idea of showing loading indicator inside keyboard so that focus eligibility (keyboard switching) can still work and has a better user experience.

While I agree on this UX improvement, this PR is still orthogonal that we want to have some functionality to present the keyboard immediately, e.g. SwiftUI's presentation(_: Modal?) driven by state change to set Modal.

So, we concluded that this PR will be reviewed separately without considering about loading-keyboard.

[andersio]

Ditto

[inamiy]

f789bcc Reverted example code.