Should we auto-type axes w/o data arrays by their range values?

[kevinoid]

If data.x and data.y are empty, layout.xaxis.range and layout.xaxis.tickformat are ignored and the plot is rendered with an x axis range from -100% to 600%. The issue can be worked around by adding at least one data point with a null y value. For an example, see https://jsbin.com/nohugit/edit?html,js,output where the first plot has no data and the second has a single null data point.

In case it is relevant, my use case is generating several adjacent plots from different types of collected data where gaps in the data are not uncommon. Occasionally a plot will have no data during the selected time range, in which case it is desirable to render an empty plot with an x axis range which matches the other plots.

Thanks for considering,
Kevin

[etpinard]

Try

var layout = {
  xaxis: {
    autorange: false,
    type: 'date',
    range: [
      '2019-01-22',
      '2019-01-23'
    ],
    tickformat: '%H:%M',
  }
};

Plotly.newPlot(
  'plot-nodata',
  [
    {
      x:[],
      y: [],
      type: 'scatter'
    }
  ],
  layout);

i.e. adding type: 'date' and I think things should work the way you desired.

Explanation: plotly needs to know that you're dealing with a date axis in order correctly parse tickformat . We auto-type axes by looking into its corresponding data array (this is x: ['2019-01-22T12:00:00'] in your second graph). So if you don't provide a data array, you have to specify the axis type yourself at the moment.

Now, perhaps inputting an axis range like you did ['2019-01-22', '2019-01-23' ] should be enough to consider that x-axis as type: 'date'?

[kevinoid]

Thanks @etpinard! That explains the behavior and type: 'date' is a much better solution than adding a null data point.

Detecting type from xaxis.range when x is empty would be convenient to cover this case. A console.warn if xaxis.type could not be detected or xaxis.range failed to parse could also point users in the right direction.

In any case, my issue is solved thanks to your suggestion. I'll leave the issue open in case you would like to track improvements so others can avoid the issue. If not, feel free to close.

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson