onDateChange fires too slow, waits until animation is fully complete
See original GitHub issueHi, Sometimes there is a race condition between the user changing the Date and the user then clicking “Save” on my form, i.e., the user might hit Save when they think the date is already set, but actually the DatePicker’s animation is not yet complete and so the onDateChange has not yet fired. Anecdotally, I feel this gap can be almost 500ms sometimes. I think the issue is that a human can visually see from the animation that the scroller is clearly going to stop at the correct date, and then proceeds to click Save on the form.
Short of adding a 500ms delay to my Save action, I’m not sure what I can do to prevent this race condition.
Maybe you can consider firing the onDateChange even before the animation is fully complete, when you can predict what the value is going to end up being.
Alternatively, it would help if you can provide some way that I can know that the DatePicker is still in motion. Maybe even an initial onPress() callback would help me know the date picker is being used.
To Reproduce Add example code that reproduces the behavior.
<DatePicker
style={styles.input_date}
date={formData.expiryDate}
onDateChange={date => {
console.log("UPDATED");
setFormData(data => {return {...data, expiryDate: date}})}
}
androidVariant='nativeAndroid'
mode="date"
fadeToColor='#CCC'
/>
Smartphone (please complete the following information):
- OS: Android
- React Native version - 0.63.4
- react-native-date-picker version 3.2.7
Thanks!
Issue Analytics
- State:
- Created 2 years ago
- Reactions:7
- Comments:6 (1 by maintainers)
Same issue here. It’s quite easy for a user to hit ‘save’ too early, while the picker is still ending its scroll animation. Visually it looks like the date already changed, but the picker did not fire onDateChange yet and a save action results in the old date. For me it would be very helpful if there was some way to know that the picker is still ‘busy’ scrolling, then I could disable the save button during this time for example.
Maybe a simpler proposal would be to add an “onDateDisplayChange” event – this would fire every time (or almost every time) the date scroller visually “enters the region” of a new date/number (and not just when the date scroller has finally stopped scrolling). So for example if the date starts at “Jan 14 2021”, when the user starts scrolling the month towards “Apr”, this event would fire for “Feb 14 2021” and “Mar 14 2021” and finally “Apr 14 2021” the moment the scroller “enters” each of those. If the events are too spammy, perhaps you could set this to fire no more often than 100ms.
Let me know if i’m making any sense 😃