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

type attribute is valid for more than just input #45

Closed
cmeeren opened this issue Sep 4, 2019 · 5 comments
Closed

type attribute is valid for more than just input #45

cmeeren opened this issue Sep 4, 2019 · 5 comments

Comments

@cmeeren
Copy link
Contributor

cmeeren commented Sep 4, 2019

Looking at the MDN HTML attribute reference, I see that the type attribute is valid not only for input, but also for e.g. button and menu. The button values are (at the time of writing) a subset of the input values, but the menu props are currently not covered.

type is also a free-text attribute for embed, source, object, and style (containing MIME types).

In any case, it might be weird calling it inputType when it's relevant for more than just input.

Related: #13 and #43

@Zaid-Ajaj
Copy link
Owner

You are right!

I am a bit conflicted on this, I like that inputTypes reflects the possible types for an input but I am not sure I want buttonTypes and menuTypes in the DSL along with a free-text value. I will take a look at what other DSL's do

@Zaid-Ajaj
Copy link
Owner

Do you have any suggestions on what should be the the property? I have a couple myself but I don't care which one gets in because I think I need to make a choice and if it is really bad (I doubt it) then it can be re-worked later

I am thinking

  • prop.withType : string -> IReactAttribute because the with* prefix is common for F# devs
  • prop.useType : string -> IReactAttribute kind of OK
  • prop.setType : string -> IReactAttribute also kind of OK but I don't like it because it resembles OOP code
  • prop.ofType : string -> IReactAttribute meh because there is a react helper in Fable.React for importing 3rd party components called the same

Even with these, withType and setType are my highest candidates because they are closest to what "setting an attribute called type represent". I also use string as input because other that inputTypes, these attributes won't be used a lot (I think)

@cmeeren @MangelMaxime what do you think?

@cmeeren
Copy link
Contributor Author

cmeeren commented Sep 10, 2019

Of those, I like withType best. I can't think of better alternatives at the moment. (Well, type', but... 😅)

I also use string as input

I suggest dropping inputType in favour of withType, and have withType surface all allowed members for any type: withType.submit, withType.date, withType.toolbar.

You could also have a string-accepting member on the prop type: prop.withType "foo" in addition to the enum props. They combine nicely.

@MangelMaxime
Copy link
Contributor

withType seems good to be

@Zaid-Ajaj
Copy link
Owner

I suggest dropping inputType in favour of withType, and have withType surface all allowed members for any type: withType.submit, withType.date, withType.toolbar.

You could also have a string-accepting member on the prop type: prop.withType "foo" in addition to the enum props. They combine nicely.

@cmeeren I like this idea because it is not good if we keep both inputTypes and withType in the DSL, I will try to implement it soon

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

3 participants