We no longer allow a user to tap the confirm button unless picker = still.

[SudoPlz]

TL/DR:
We no longer allow our user to tap the confirm button unless the picker is still.

Long version:
Up until now when the user interacted with the picker, if someone tapped on the confirm button, the state was not yet changed and thus the picked value would be old and miss-leading.
The DatePickerIOS does not update on the fly, and before it even manages to dispatch an update, our component is unmounted and thus the state is lost.

We no longer allow our user to tap the confirm button unless the picker is still.

They can always tap the cancel button anyway.

[mmazzarolo]

I like it, thank you :)
Merged, I'll release it as soon as #39 gets merged.
Could you also provide a link to the issue on the react-native repo? I'd like to link it in the comments.

[SudoPlz]

Not sure which one it was because I had a gazilion of tabs open, but it must be this one: facebook/react-native#8169

The problem with DatePickerIOS is that it doesn't expose many of it's parameters, so we have limited control over what it can do.

[mmazzarolo]

Landed on v4.6.0.
Let me know if it works correctly.
I expanded a bit the comment and I also noticed that userIsInteractingWithPicker could also be removed from the state (but I left it there anyway).

[SudoPlz]

Thanks for that, but if you remove userIsInteractingWithPicker it will allow the confirm button to be pressed while the user is interacting with the picker and that's exactly what we're trying to avoid there..!
I'll try 4.6.0 on monday!

[mmazzarolo]

@SudoPlz
I didn't explain myself properly, my bad: this.state.userIsInteractingWithPicker can be moved from the state to this.userIsInteractingWithPicker, because it is an info that is not used in the render.

edit: Ha! Just checked, it is used to compute the customConfirmButtonWhileInteractingIOS, it should be declared as part of the state (like it is right now) and not as a class variable then, my mistake :)

[SudoPlz]

yep.
No problem!