Handle weekday strings in rangebreaks

[archmoj]

Follow up of #4614 and #4655

• convert string bounds e.g. Monday (or 'mon`) to day of week indices between [0, 6].
• auto default to day of week when using day strings e.g. Monday or 'mon`.
• update description
• add jasmine tests

Demo.

@plotly/plotly_js

[alexcjohnson]

I don't think you have to do this slice(0, 2) - coerce for info_array already does this.
But if somehow I'm mistaken about that, you'd need to also shorten bnds so you don't lengthen itemOut.bounds again in the loops below.

[archmoj]

I don't see any place where itemOut.bounds.length is changed.

[alexcjohnson]

itemOut.bounds[i] = bnds[i] = q;

[archmoj]

Good call. I revised the new logic in 550a375.

[alexcjohnson]

Again, you don't need to worry about the length of bnds at all - coerce handles that so bnds (and itemOut.bounds) is either undefined (since it has no default value) or it's an array of length 2 - or less, I just tested this, if you pass in a shorter array coerce isn't going to pad it since the inner values don't have defaults either, but that's OK, it'll just look like undefined for missing values and get filtered out in the type checks.

Can you please take all these length checks out? We put a lot of effort into making coerce do the right thing so the individual supplyDefaults functions could be simple and readable.

[archmoj]

Good call. Addressed in 84c2a6f.

[alexcjohnson]

This could be sped up a bit with an object lookup rather than indexOf

var dayStrToNum = {
    sun: 0,
    mon: 1,
    ...
}

return dayStrToNum[str];

[alexcjohnson]

and possibly bail out early if v isn't already a string, rather than converting to a string only to discard it later.

[archmoj]

Good calls! Done in db2c3a3.
Curious to know if there is a good article on this?
At the moment, there are quite a number of places that indexOf !== -1 is applied, so please feel free to open an issue for that.
Thanks.

[alexcjohnson]

Not sure about an article... you find a lot of people saying "hash lookup is O(1) but indexOf is O(n)" but that's as far as it usually goes.

Here's a jsperf showing the general trends: https://jsperf.com/array-indexof-vs-object-key-lookup2/12 - basically, object lookups hardly scale with the number of keys but indexOf scales linearly. So indexOf can be a nice way to simplify if (a===b || a===c || a===d) -> if ([b,c,d].indexOf(a) !== -1) - but more than a few items and it's better to turn the problem into an object lookup.

Also of course object lookups only support strings... looking forward to when we stop supporting IE and can use Set!

[archmoj]

@alexcjohnson thank you!!

[alexcjohnson]

clever way to avoid having to distinguish 0 from undefined :)

[nicolaskruchten]

I <3 this!! cc @chriddyp

[alexcjohnson]

redundant - and dangerous - q='' would be turned into 0 for example. We should only cast to number when the value has already passed isNumeric (but might be a numeric string).

Also I don't think we should floor, we should just discard values that aren't integers (ie enabled=false). For one thing, that way if we ever add support for fractional days it won't break any existing behavior.

Can't this numeric validation be pushed into the if(pattern === DAY_OF_WEEK) loop above, and only executed if we didn't already convert from a day name to integer?

[archmoj]

Good call. Fixed in 9a0416a.

[alexcjohnson]

Alright, I think we've got it! 💃