Test mock with numeric "offsetgroup" value

[hmf]

The mock bar-alignment-offset.json has the following trace:

    {
      "type": "bar",
      "marker": {
        "color": "orange"
      },
      "opacity": 0.6,
      "name": "B",
      "legendgroup": "B",
      "showlegend": false,
      "hoverinfo": "text",
      "hovertext": "a0",
      "xaxis": "x",
      "yaxis": "y",
      "alignmentgroup": "a",
      "offsetgroup": 0,
      "x": [
        1
      ],
      "y": [
        1
      ]
    },

Note that the "offsetgroup" has a numeric value. But the schema indicates:

valType : "string"

The few examples I have found in Plotly's Github and project/product sites seem to use strings. Is the mock incorrect?

TIA

[archmoj]

The number is casted to string in this case.

 offsetgroup = "0"

[hmf]

@archmoj thanks for the info.

I understand that Plotly does this. Maybe I phrased this incorrectly. What I need to know is can the Mock that uses a numeric value be considered incorrect?

Just for some background - I am setting up a round-trip test for a Scala wrapper to read and output the Plotly JSON documents according to the schema (much of the code is generated automatically via the schema). This means that it is not trivial to add support for such conversions or even support deprecated elements.

In such cases, I will opt to change the mocks but must ensure that these changes are correct. Hence the question: is the mock incorrect and will the change I make (use a string) be in accordance with the schema (i.e.: not a schema error)?

Appreciate any feedback on this.

[alexcjohnson]

In general we accept numbers in string fields. I wouldn't exactly recommend it, but it is officially supported and they get cast to strings. The only exception is attributes labeled strict: true in the schema - these will reject numbers as input and only accept values that are already strings.

[hmf]

For the Scala wrapper I will assume "strict" and use numeric values only. Easier to maintain the mock change. Thanks.