Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add async-
CustomInput
support #182Add async-
CustomInput
support #182Changes from 2 commits
bb11eba
ad713ac
bd6df2f
ef12cd7
f789bcc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to change
CustomInputComponent
to support this? Why can't we just returnself
when state isnil
? 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 thestate
isnil
it means there's noCustomInput
so we don't need aCustomInputComponent
but once that changes we can then build aCustomInputComponent
to display that input.I'm not sure if I'm missing some detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
state = nil
doesn't mean we don't usecustomInput
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I should rename method e.g.
func customInput(immediatelyWhen:...)
so that "immediately" belongs to state existence.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ofcustomInput
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(For sure diffing optimization will be more nice, but we won't probably invest too much here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#146 is meant to tackle that. But I'd be surprised that there is any deleting animation. It should be a subtle cross-fade.