Stroke style type feedback about community-group HOT 3 OPEN

One additional property that could be useful is stroke alignment: whether it draws inside the edge of the object on top of the fill, or outside of the object.

from community-group.

I think there’s a unique problem with the string | object polymorphism here which doesn’t exist on other tokens.

font, for example, may be a string | string[]. But if string is passed, you could normalize that by simply placing that in an array, and it would be equivalent (in other words, you can “expand” one type into another). This form of polymorphism is easy to deal with because they aren’t necessarily distinct types; one is simply a shorthand for another.

I would expect for strokeStyle the string value should be “expandable” to the object value, but that doesn’t seem to be the case. If I’m reading this right, the object value would always be the dashed style? If so, I’d suggest the following:

{
  "alert-border-style": {
    "$type": "strokeStyle",
    "$value": {
      "style": "dashed",
      "dashArray": ["0.5rem", "0.25rem"],
      "lineCap": "round"
    }
  }
}

Having a "style" that corresponds to the string value (feel free to bikeshed the name; I’m not opinionated about “style”) allows the two types to be interchangeable. So "$value": "dashed" and "$value": { "style": "dashed" } are two ways to write the same thing.

Of course, that begs the question of whether or not other styles ("$value": { "style": "solid" }) also have attributes that could be set. I’d probably lean toward simply letting the implementor decide which additional attributes apply and which don’t (e.g. say dashArray was set on a solid stroke and the tool author decided to ignore that attribute without throwing an error). But I could realistically see a core set of attributes applying to multiple styles and not being mutually-exclusive to one.

Alternate suggestion: if each different stroke type needs different values and there is little to no overlap, (i.e. there are “sub-types,”) I’d argue those are actually not the same type and need to be split apart.

In that instance, splitting apart one stroke into multiple e.g. $type: "solidStroke", $type: "dashedStroke", etc., would make it easier both on the author and the tool implementor than dealing with complex polymorphic types where one part of $value has implications on the rest of the shape (hidden types).

from community-group.

I think if we're coping dashArray or lineCap. Because we're also referring here to SVG. There should also be other values like:

• lineJoin: "round" | "bevel" | "miter"
• miterLimit: number
• dashOffset: number

from community-group.