prop.inputType -> prop.input.type for better discoverability?

[zaid-ajaj]

prop.inputType -> prop.input.type for better discoverability?

[Zaid-Ajaj]

Hello @cmeeren, the problem with this is that I didn't want want to use apostrophe or back ticks for any of the properties because it always looks foreign and weird for F# beginners, I find the current way of prop.inputType.xxx OK-ish but already has too many dots prop.xxx.yyy; So I am not sure whether adding another level of nesting would help just to have property have a single word per level.

I am open to suggestions, although with this library, it seems to be subjective per user and it is really hard to come up with a consensus that will kind-of satisfy everyone

[cmeeren]

Personally I find hierarchies pleasant, but I admit that everyone might not feel the same.

In this specific case, I am thinking that, as a general rule, it's easy to do prop.input for all input-related props, prop.appBar for all appBar-related props (MaterialUI component), etc. It enhances discoverability.

For example, there are variant and color enum props for a lot of the Material-UI components. So when I'm working with a button and not sure exactly what I'm looking for, I'd rather not have to type prop.variant and then sort through tens (if not hundreds) of xVariant, yVariant, buttonVariant, zVariant, but instead just go to prop.button and see all available button props.

Just my two cents. :)

[Zaid-Ajaj]

Since Feliz doesn't itself have element-specific properties, adding this one wouldn't make a lot of sense and the current implementation is good enough for now

[cmeeren]

Agreed. I'm using this for MUI, where it makes more sense.

[cmeeren]

Just for the record, I just came across the Elm variant, which is called type_:

https://github.com/elm-lang/html/blob/6dee805cd03bf8937936dd564db1c04c64efc5ab/src/Html/Attributes.elm#L428-L433