Is there a way to fire a callback with startDate and endDate values only when there is a startDate, an endDate and the date picker isn't focused anymore. Something that tells that startDate and endDate are the final values and not something inprogress?
Can you clarify? Because the component is fully controlled, you always have access to date values and focus value in the state of your wrapper component. The onDatesChange and onFocusChange callbacks should give you access to the new values as they change.
What exactly are you trying to do?
I have a similar problem. The use case being that once a user selects start and/or end dates, and the DateRangePicker is closed (i.e. focusedInput === null), then I want to trigger an API call to refresh data in the table. The problem I run into is that setState is not synchronous, so when I check if the focusedInput is null or I try to grab the values for the starteDate and endDate... they are usually old values. Here is how it looks
onDatesChange({ startDate, endDate }) {
let {focusedInput} = this.state;
if (!focusedInput) {
dispatchAPICall(startDate, endDate);
}
this.setState({ startDate, endDate });
}
onFocusChange(focusedInput) {
this.setState({ focusedInput });
}
This makes me think it's not an issue with react-dates however.
I am trying to fire an ajax call only when the set of [startDate, endDate] is changed and not one or the other. I don't know how to achieve this.
Is the same that davekaro commented.
@soda29 they're never both changed at the same time - each is changed separately by the user, so you yourself have to decide when both changes have come in and you want to make your Ajax call.
We need this too. There currently isn't a reliable way to know when the picker is being unfocused.
For instance, log out here:
onFocusChange={focused => {
console.log(focused)
this.setState({focused})
}}
When you click the start date, you will see this:
'startDate'
null
'startDate'
'startDate'
When you switch to the end date, you will see this:
'endDate'
null
'endDate'
'endDate'
And when you close the datepicker, you will see:
That last null is great, and is exactly what @davekaro and I are looking for, but the other nulls that are randomly fired off during the other actions makes this unreliable.
@tannerlinsley There's actually some changes in https://github.com/airbnb/react-dates/pull/217 that will fix the quadruple firing (and make onFocusChange a little bit more reliable) at the least.
@majapw That's good to hear. Those changes would effectively close this issue :)
@davekaro and everyone else, a temporary workaround that I'm using works okay for now:
onFocusChange={focused => {
this.setState({focused})
if (this.state.focused === 'endDate' && !focused) {
// Dispatch an update
}
}}
This should only fire when the picker is updating from 'endDate' being focused to not being focused at all.
I have no idea why it doesn't fire during the quadruple events from clicking 'endDate'. Likely because setState is synchronous, it hasn't updated yet.
@tannerlinsley But it seems like onFocusChange fires before onDatesChange. So when !focused the last onDatesChange has not been called yet.
This is still a problem for us. Hoping that the latest version has fixed the bug
I have the same problem ... would love to get a fix for this.
I've faced a slightly similar problem and this was a workaround. The logic sits in the componentDidUpdate lifecycle hook.
onFocusChange(focusedInput) {
this.setState({ focusedInput });
}
componentDidUpdate(prevProps) {
const { focusedInput, startDate, endDate } = this.state;
if (!focusedInput && (startDate && endDate)) {
// fire callback
}
}
Most helpful comment
I have a similar problem. The use case being that once a user selects start and/or end dates, and the
DateRangePickeris closed (i.e.focusedInput === null), then I want to trigger an API call to refresh data in the table. The problem I run into is thatsetStateis not synchronous, so when I check if thefocusedInputisnullor I try to grab the values for thestarteDateandendDate... they are usually old values. Here is how it looksThis makes me think it's not an issue with
react-dateshowever.