Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to avoid type conversion clutter in Elm SVG code

Tags:

types

svg

elm

In Elm's SVG modules, all attributes seem to expect String type parameters, which probably makes sense from a DOM point of view. Semantically, however, many attributes are numbers, especially coordinates, radii, widths, etc, which I happen to use a lot when generating graphics algorithmically.

My understanding is that Elm does not have implicits like Scala, and that implicit conversions are frowned upon, probably for good reason.

On the other hand, I'm not willing to clutter my graphics generation code with x <| toString <| myX; too much visual noise.

What I do so far is define a module with functions like

x_ = x << toString
y_ = y << toString

which allows me to use x_ myX in the code.

Is there a more elegant solution I am not aware of?

How are others dealing with this?

like image 636
DCS Avatar asked Oct 19 '22 06:10

DCS


1 Answers

The attributes are String because the specifications allow for different units (px, cm, etc.)

The best approach would be to craft a series of unit helpers that help you output the right thing. px, cm, deg, etc.

You could have a helper that's just an alias for toString. I have used just as in x (just myX) in some CSS code I've wrote (for some reason that's how I wanted to read the code) and I've seen s as in x (s myX) (short but can be confusing).

Maybe the best is to use something like int as in x (int myX) or float as in x (float myX)

Another option that might be more elegant than x_ is to import Svg.Attributes as SA and write x = SA.x << toString. You can also move these definitions in a module and import that instead of Svg.Attributes.

like image 190
pdamoc Avatar answered Oct 21 '22 21:10

pdamoc