Closed Zaid-Ajaj closed 5 years ago
You're right, much better to use stringenums, thank you!
I'm getting some conflict with the Display
StringEnum and Fulma's Display.Option
. The weird thing is when I try to fully qualify the type like Fable.React.Props.Display.Flex
the compiles thinks this is the CSSProp.
The only solution I've found to fix it was using a type alias: type CSSDisplay = Fable.React.Props.Display
Does it work if you give the compile a hint that you are using CSSProp
? i.e.
div [ CSSProp.Display Display.Flex ] [ ]
The weird thing is when I try to fully qualify the type like Fable.React.Props.Display.Flex the compiles thinks this is the CSSProp.
F# compiler or Fable? sounds like a bug to me because you are using a constructor of Display
type (the Flex
case) and not a constructor of CSSProp
(the Display
case)
Does it work if you give the compile a hint that you are using CSSProp? i.e.
Nope, same issue :/
F# compiler or Fable?
I can see the error both in the IDE and Fable's log output
I saw this problem occurred several times in my projects.
I tried to re-order the open
statement or to fully qualified the whole path but it didn't work.
I will add "-Options" to the StringEnums to avoid this issue (DisplayOptions, TextAlignOptions, etc). Does it look right?
SGTM, but still this looks like a bug in type-inference for cross-project types. We need to report it somewhere, maybe f# compiler repo or track in Fable repo
This PR adds a couple of type definitions to make usage of CSS properties type-safe. It is not much but it only covers a couple of commonly used inline styles:
This is of course a breaking change because the properties such as
Display
were takingobj
as input where the user supplies a string a everything works out (hopefully) but now the types are restricted to the defined DU'sThis PR doesn't affect bundle sizes. All DU's are simple
StringEnum
s.I thought it would be a good time to work on these breaking changes since we are already updating to a major version.