Plotly.js: rangebreaks sometimes draws the gridline on the wrong point

[nicolaskruchten]

See Jan 3 here: https://codepen.io/nicolaskruchten/pen/oNXQmLR?editors=1010

[alexcjohnson]

It's not drawing the gridline on the wrong point; it's drawing a gridline inside the break, but due to the way the breaks work (removing from the first instant of Saturday until the last instant of Sunday), the break is at Monday.

Simplest fix I can think of here is to shift the auto tick0 to a Monday when we remove the weekend - more precisely, take the first day of week break and shift tick0 to the day in its bounds[1]

That happens here:

https://github.com/plotly/plotly.js/blob/5b6abbb94f06eae9e93d68ac6ec74ae1ee3ebb50/src/plots/cartesian/axes.js#L542

but mostly here (you can see we explicitly chose Sunday):

https://github.com/plotly/plotly.js/blob/5b6abbb94f06eae9e93d68ac6ec74ae1ee3ebb50/src/plots/cartesian/axes.js#L816-L819

[alexcjohnson]

Oh actually ignore line 542, I'm not sure when that happens but I suspect it's largely for pseudo-axis fallbacks.

[archmoj]

Removed my previous comment which was not correct.

[nicolaskruchten]

@alexcjohnson are you proposing a weekend-specific fix or do you think this is a generalizable approach?

[nicolaskruchten]

Also, we should make sure this works well with bars and tickson = "boundaries"!

[alexcjohnson]

I was suggesting weekend-specific. I feel like any attempt to generalize beyond that will create other confusion... maybe not, maybe if you also remove a specific Monday we could make the tick say Tuesday somehow. That seems tougher to implement though. We could try and just use the end of the break as the tick value (ie reverting the special logic I had @archmoj figure out to position the tick at the end of the break but label it with the label it would have gotten in the absence of breaks) and see if the label comes out right. I just worry about edge cases like if you remove until 1pm Monday, will the tick say Tuesday even though there are 11 hours of Monday left after the tick? The reason for my concern is that we aggressively set the tick label rounding based on dtick and tick0, so if we start moving the ticks off of even multiples of dtick it's unclear what will happen.

Also, we should make sure this works well with bars and tickson = "boundaries"!

in that future where breaks apply to category axes, or tickson applies to dates 😁

[nicolaskruchten]

in that future where breaks apply to category axes, or tickson applies to dates 😁

Oh right :) Phew!

[nicolaskruchten]

use the end of the break as the tick value

This seems like a good idea to me actually, and in fact will be more forward-compatible with a world where we actually render a gap where the break is, right? The break would come right before the gridline/ticklabel in that case. Using some value in the break is not going to work well in that case.

[alexcjohnson]

OK, we can try it. Maybe it'll just generally work out? It'll certainly be simpler code, with apologies to @archmoj for the extra complexity (specifically the _realV stuff) that will just need to be reverted to do it this way.