DateRangeSlider: value and value_throttled turned to DateRange Parameters #3515
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.
The
value
andvalue_throttled
Parameters of theDateRangeSlider
widget were of the Parameter typeTuple
. This PR turns them intoDateRange
Parameters. Without that:DateRange
Parameters after Allow (de)serializing CalendarRange and DateRange Parameters param#625 is merged, and maybe more Parameters in the future.Before this PR the default value of
value
was(None, None)
. This default value is not accepted by theDateRange
Parameter that doesn't accept anyNone
in the tuple it holds. The default is nowNone
, which forced me to make some more changes, including no longer having theDateRangeSlider
inheriting from_RangeSliderBase
since it had logic that diverted from the new logic required to handle this change in default value.Also, I noticed that before the PR it was possible to instantiate the widget without providing any parameter (e.g. without
start
orend
). This behavior is common to a lot of widgets and is tested in thetests/widgets/test_base.py
file. This behavior is still respected after the changed made in this PR. However, I've noticed that not providing thestart
orend
parameters did come with some issues, even if the widget could be instantiated it could never be rendered, Bokeh needs the start/end properties to be set. This should probably be better handled (in another PR!), for now I've just added a warning when start or end aren't set on instantiation.