-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prop.inputType -> prop.input.type for better discoverability? #13
Comments
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 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 |
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 For example, there are Just my two cents. :) |
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 |
Agreed. I'm using this for MUI, where it makes more sense. |
Just for the record, I just came across the Elm variant, which is called |
It seems that Feliz places component-specific props in separate types. For example,
prop.inputType.xx
. Could these be more discoverable ifinputType
was separated into element + prop, so that it wasprop.input.type.xx
? Seems to be a bit more clean. (Material-UI have a lot of component-specific props and would require a lot of these.)(You'd have to name it
type'
or similar for this specific example, of course.)The text was updated successfully, but these errors were encountered: