d2l-input-time-range attribute order matters with non-default interval
dlockhart opened this issue · comments
When you don't set a start and/or end value (or have invalid values) in <d2l-input-time-range>
and you have an interval set to something other than the default (30), the order of the attributes can lead to different results.
This is because when computing the initial start and end values, it uses the current time and rounds up to the nearest interval. But if the value attributes are specified before the interval attribute in the markup, it'll use the default interval of 30 to do this calculate. Then later when the interval property is initialized, the value doesn't recalculate and it's too late to do so.
For example, this functions correctly, resulting in a start time of 15:20
(since 15:15 isn't on the interval):
<d2l-input-time-range
enforce-time-intervals
time-interval="10"
start-value="15:15"
></d2l-input-time-range>
However, if you flip the time-interval
to be set last, it'll incorrectly result in a time of 15:30
, using the default interval of 30:
<d2l-input-time-range
enforce-time-intervals
start-value="15:15"
time-interval="10"
></d2l-input-time-range>
The same issue exists with enforce-time-intervals
since it's also part of the determination.
Closing as this appears to be fixed now. Tests were added for this case here #2335
Closing as this appears to be fixed now.
Cool! My guess is Lit 2 quietly fixed this.