Skip to content
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

Closed
cmeeren opened this issue Aug 11, 2019 · 5 comments
Closed

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

cmeeren opened this issue Aug 11, 2019 · 5 comments

Comments

@cmeeren
Copy link
Contributor

cmeeren commented Aug 11, 2019

It seems that Feliz places component-specific props in separate types. For example, prop.inputType.xx. Could these be more discoverable if inputType was separated into element + prop, so that it was prop.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.)

@Zaid-Ajaj
Copy link
Owner

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
Copy link
Contributor Author

cmeeren commented Aug 12, 2019

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. :)

@cmeeren cmeeren mentioned this issue Aug 12, 2019
@Zaid-Ajaj
Copy link
Owner

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
Copy link
Contributor Author

cmeeren commented Aug 24, 2019

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

@cmeeren
Copy link
Contributor Author

cmeeren commented Nov 8, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants