Nasty Side Effect of Clamping the Value

[akc42]

I have an element which uses custom element with iron-range-behaviour inside a complicated nested dom-repeat arrangement. The dom-repeats are used to draw a large calendar - with slots for filling in each day with data. The data is retrieved using ajax later, and the paths to this data updated when the data is received. The day data is essentially information that can be calculated statically (the date, the day names, and the data to be fetched is the number of slots available and the number of slots filled. I have initialise these slots to something before it is fetched - the convenient value is 0.

I am then doing the following:-

 slot=0;
 for(week = 0; week < this.weeks.length; week++) {
    for(day = 0; day < this.weeks[week].length; day++) {
        path = 'weeks.' + week + '.' + day
                if(slot < response.slots.length
                  && this.weeks[week][day].date == response.slots[slot][0] ) {
                  //we have an entry
                  s = response.slots[slot];
                  this.set(path + '.appts', s[1]);
                  this.set(path + '.slots', s[2]);
...

I couldn't figure out why, despite knowing the responses being fired back, had values for appts, they were all showing as 0.

It turns out that in order to ensure the ratio that iron-range-behaviour calculates is between 0 and 100% that the value is clamped between the min and max values.. There is no word about this clamping in the iron-range-documentation.

What was happening in my case is that I set the value before the max, so the value got clamped to 0 (as max was zero) and then max gets set to its amount.

Why does the clamped value need to be written back to the property. Cannot it just be used in the calculations.

[PIR3M]

I also got a similar issue with paper-progress element which is also using iron-range-behavior.

I'using paper-progress this way: inside a dom-repeat:

<paper-progress max="[[max(item.booked, item.available)]]" value="[[item.booked]]">
</paper-progress>

item.booked = 120 item.available = 360 in this case, max should be 360.

The problem is in this declarative way, I CAN'T ensure that max is initialized before the value and if not, the value will be clamped to the default max of 100...

In my opinion, the max attribute of iron-range-bahavior should not have a default value of 100. This way, the observer:

observers: [
    '_update(value, min, max, step)'
  ], 

will olny be triggered when the max value is set and so the value won't be clamped to the default max of 100..

[akc42]

Actually I this same afternoon as @PIR3M I think I have hit a related issue with paper slider. I am setting the max and min through databinding because the I need to convert the max and min to minutes from midnight based in some times. The databinding system has initialized min to 540 (9:00am) but the max is at its default value of 100 still. This gives negative steps, which then cause the slider to crash.

I am about to report this issue at the paper-slider repository, but I saw this comment here on my way there.