JSON Mock with numeric Funnel.line.dash value

[hmf]

I have the mock funnel_vertical_overlay_custom_arrays.json that sets the line dash to 10. Would I be correct in assuming that a value of "10" is ok (i.e: changing the mock value to string is correct)? For the values 0 to 5 I assume 0 refers to "solid", no? If so I guess the value 10 is incorrect?

Looking at the schema below it seems like this is a candidate for "enumerate". This would allow the Scala API to set the correct value. I see that issue #2903 has already referred to this possibility. Would it make sense for me to make a request?

TIA.

                "connector": {
                    "line": {
                        "color": {
                            "valType": "color",
                            "role": "style",
                            "editType": "style",
                            "description": "Sets the line color.",
                            "dflt": "#444"
                        },
                        "width": {
                            "valType": "number",
                            "min": 0,
                            "dflt": 2,
                            "role": "style",
                            "editType": "plot",
                            "description": "Sets the line width (in px)."
                        },
                        "dash": {
                            "valType": "string",
                            "values": [
                                "solid",
                                "dot",
                                "dash",
                                "longdash",
                                "dashdot",
                                "longdashdot"
                            ],
                            "dflt": "solid",
                            "role": "style",
                            "editType": "style",
                            "description": "Sets the dash style of lines. Set to a dash type string (*solid*, *dot*, *dash*, *longdash*, *dashdot*, or *longdashdot*) or a dash length list in px (eg *5px,10px,2px,2px*)."
                        },
                        "editType": "plot",
                        "role": "object"
                    },

[archmoj]

To me this looks like a good catch!

Right now 10 coerced as "10".
@alexcjohnson
Shouldn't the dash.valType be `enum?

[alexcjohnson]

Also that mock has marker.line.dash which is not supported, we should remove that from the mock. So this is just about connector.line.dash.

The key part of the attribute description is "or a dash length list in px (eg *5px,10px,2px,2px*)" - That's a freeform string - following a pattern, but not enumerable. But we list values in the schema because these are special values that are interpreted dynamically. Aside from solid, these do not have a fixed representation as dash length lists, as we scale the dash lengths with line width.

Side note: according to the docs you actually should not use "px" in the attribute as we suggest in the description, though AFAIK browsers universally accept it that way.

10 is coerced to "10" and then interpreted by stroke-dasharray as "10px on, 10px off."
0 ends up solid, but only because the browser doesn't know what to do with "0px on, 0px off", not because we assign values to the special strings.

[hmf]

@alexcjohnson I don't quite understand when you say

That's a freeform string - following a pattern, but not enumerable."

Does that mean it should not be made into an enumerate? Note that this type of free-form check is already made in another enumerate. More concretely in the Layout.shapes.item.shape.xref attribute (see excerpt from schema below). In this case I am using the schema to generate a method that checks the string format (the method name is hard-coded but have to be changed).

            "shapes": {
                "items": {
                    "shape": {
                        ...
                        "xref": {
                            "valType": "enumerated",
                            "values": [
                                "paper",
                                "/^x([2-9]|[1-9][0-9]+)?$/"
                            ],
                            "role": "info",
                            "editType": "calc",
                            "description": "Sets the shape's x coordinate axis. If set to an x axis id (e.g. *x* or *x2*), the `x` position refers to an x coordinate. If set to *paper*, the `x` position refers to the distance from the left side of the plotting area in normalized coordinates where *0* (*1*) corresponds to the left (right) side. If the axis `type` is *log*, then you must take the log of your desired range. If the axis `type` is *date*, then you must convert the date to unix time in milliseconds."
                        },
   ...
}

[alexcjohnson]

Ah I had forgotten that we labeled xref and yref as enumerated. We don't actually use that schema definition in coercing these values, for that purpose we create a list of all the available x or y axes and use that to validate the input.

I suppose in principle we could do the same thing for dash, add a regex to the values array and use a dedicated validator just for dash attributes. That sounds a bit tricky to get right but it would be doable. I wouldn't see that as a real high priority, but if you're motivated to do it feel free to submit a PR 😉

[hmf]

My JS knowledge is next to 0 and getting to know Plotly.js code is not doable. I have already bitten off more than I can chew on this Scala wrapper thingy. Went down this rabbit hole thinking I would have it done in a couple of weeks. 8-(
I will change the mock to string and hold off on the validation.
Thanks for everyone's help.