Issue 510 fix clearing date callback #511
Conversation
| if (setProps && date !== null) { | ||
| setProps({date: date.format('YYYY-MM-DD')}); | ||
| if (setProps) { | ||
| setProps({date: date ? date.format('YYYY-MM-DD') : null }); |
There was a problem hiding this comment.
This looks good to me. I'm a bit concerned about backward compatibility though, as it's been this way for as long as these components have existed and users may depend on null never arriving in their callbacks. @chriddyp thoughts? Do we need to make this behavior opt-in?
There was a problem hiding this comment.
OK, we discussed this internally, the consensus is we're happy to call the old behavior a bug, this PR a fix, so no need for opt-in 🎉
|
Thanks @derekclee! Really appreciate seeing the PR come with tests already in place 🏆 Aside from the question about backward compatibility that I'm not immediately sure how I feel about (if we were starting from scratch I'd much prefer to keep it simple like you have here), the only issue I see is linting - we use |
- When clearing a date, `date` is set to `null` but `setProps`
was not called.
- Made sure to always call `setProps` on any date change.
derekclee
force-pushed
the
issue-510-fix-clearing-date-callback
branch
from
b745c51
to
b29653d
Compare
|
@alexcjohnson I ran Our use case of the clearing is that we initially have a blank date filter on a visualization. The date may not always be present in the data thus having the filter optional is important. A user is able to filter by a date. If the date was not clearable, the user would have to do a full refresh of the application to get it back to the original state. I can add an opt in prop if needed. On an unrelated note, I originally tried to use the |
| @@ -1076,6 +1076,8 @@ def test_tabs_with_children_undefined(self): | |||
|
|
|||
| self.startServer(app=app) | |||
|
|
|||
| self.wait_for_element_by_css_selector('#tabs-content') | |||
There was a problem hiding this comment.
There was a percy diff - the image produced in this PR prior to this commit was actually the right one, dunno how the incorrect one got approved... but to make that more robust I added this wait for the correct element to be on the page.
|
Thanks @alexcjohnson ! |
Fixes a problem with
<DatePickerSingle />where the callbacksetPropswas not called when a date was cleared.