Open tesk9 opened 2 years ago
Oo, yeah, hmm. Definitely these types of type tricks are the hardest for elm-codegen
to resolve.
There is a workaround, you can add Elm.withType
to skip what the inference thinks and just have it generate what you want. You can also construct an Annotation
to use with Elm.withType
by using the values in Gen.Css.annotation_
So, I think that would be |> Elm.withType Gen.Css.annotation_.px
Users should be totally Ok to use file
if they're working with the Gen.*
stuff, I just need to figure out what's going on, type-inference wise.
Thank you for the Ellie allows me to put that into my tests for this kind of thing.
Using generated package code for
rtfeldman/elm-css
works when usingElm.ToString
helpers, but not when usingElm.file
.When using
Elm.file
,Gen.Css.marginRight (Gen.Css.px 1)
will cause an error likeELM-CODEGEN ERROR -- I found Css.LengthOrAuto compatible_0 But I was expecting: Css.Px
I believe this is because elm-css does some type-trickery in order to allow helpers that take "different" units, like
pct
,px
, etc. ACss.Px
is aExplicitLength
, which is aCss.LengthOrAuto
.Ellie example illustrating the problem when using Elm.file
Should users only use
file
if they're working with generated code that results fromGenerate.elm
, rather than usingGen.*
directly?