prop type check

[byronz]

@alexcjohnson @chriddyp I have a concern about the current state of our defined PropTypes,

one example is draggable: PropTypes.string, but per HTML reference it's an enumerated attribute with {true, false, auto}.

we don't have another useful attribute inputmode, which is also an enumerated list, and it's a good demo case for <textarea> and

this fixes #107

[byronz]

@plotly/dash-core a quick glimpse of generate-component.js and extract-attributes.js, and also found a closed issue create by ryan, I think it makes sense to revisit the accuracy of the prop types definition for global attributes.

[chriddyp]

I think it makes sense to revisit the accuracy of the prop types definition for global attributes.

👍 . I just found this data in a structured format here: https://github.com/iandevlin/html-attributes, seems like we could use that in our component generation script.

[chriddyp]

also might need to evaluate how we deal with booleans too. I think we should accept them and coerce to "true".

not sure what to do about False - do we compile to "false" or do we omit? in the html spec, for a value to be false, it needs to be omitted rather than set to "false"

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes#Boolean_Attributes:

Some content attributes (e.g. required, readonly, disabled) are called boolean attributes. If a boolean attribute is present, its value is true, and if it’s absent, its value is false.

However, I believe React will just ignore it now: https://reactjs.org/blog/2017/09/08/dom-attributes-in-react-16.html & https://reactjs.org/docs/jsx-in-depth.html#props-default-to-true

[byronz]

the draggable example itself is also tricky, if you don't set, it's auto, when you set it, must be true and false, so a simple enum list might not be ideal

[alexcjohnson]

@byronz can we close this PR (and issue #107), since plotly/dash-renderer#100 does this for all components?