Further discussion with @emilykl @archmoj:

• The original behavior of converting infinity and Nan values was added because np.Inf and np.Nan couldn't be correctly stored in JSON objects, so these values were converted to null. It appears that base64 is correctly converting these values before sending them to plotly.js, so this is not an issue (as far as we know). Plotly.js may not handle Infinity or NaN values in all cases, but we did check this for scatter plots. Plotly.js ignores these values - this is the result that we expect.
• We tested this out with the changes from Use plotly.js base64 API to store and pass typed arrays declared by numpy, pandas, etc.  #4470, and we observed the following in the data in the graph div:
  • np.inf becomes Infinity
  • np.nan becomes NaN
  • -np.inf becomes -Infinity

Still need to add tests for the above cases ^^ in plotly.js?

@alexcjohnson Does this seem right to you?

Oh this is cool, b64 can actually encode more info than regular JSON. I think this is fine behavior, but most of the time the behavior will (ie should, and we should add some tests) be indistinguishable from null. Meaning if infinity or nan values are in coordinates they should not be displayed, nor should they impact autorange. I suppose in principle a bar chart could show a bar to infinity (without impacting range) but I wouldn’t implement that without a clear use case. Otherwise about the only cases I can see this having a concrete effect are colorscale (+/-inf should show the color at the corresponding end of the scale, as any other out-of-range value would) or hover (via customdata or other non-coordinate fields in the hovertemplate)

I can't see any reason to not take advantage of this except possibly the extra work it would take to handle the cases @alexcjohnson outlines (e.g., making sure inf hits the margin of the color scale), so I'm 👍 to having Infinity and NaN rather than forcing conversion to undefined.