Fix prop types #523

chriddyp · 2019-04-12T03:15:07Z

in preparation for plotly/dash-renderer#100

chriddyp · 2019-04-12T03:18:22Z

a QA example: https://gist.github.com/chriddyp/93d5c12b88d7333f56457b867e94d7b6

src/components/Input.react.js

byronz · 2019-04-12T18:49:56Z

@chriddyp To keep DRY 🐫 we might need a similar mechanism to share some of the global attributes definition like in HTML components.

src/components/RangeSlider.react.js

chriddyp · 2019-04-13T20:39:07Z

fixes #457
fixes #505

chriddyp · 2019-04-13T20:41:01Z

To keep DRY 🐫 we might need a similar mechanism to share some of the global attributes definition like in HTML components.

Yeah I agree. I'd like to punt this one to the future. For now, just want to make sure that we won't be breaking any valid code.

chriddyp · 2019-04-13T20:43:19Z

Alright, I've addressed your comments @alexcjohnson @byronz

alexcjohnson · 2019-04-13T22:12:50Z

CHANGELOG.md

+    - `inputmode` is now `inputMode`
+    - `maxlength` is now `maxLength`
+    - `minlength` is now `minLength`
+- Updated property definitions of various components in anticipation of upcoming component validation (https://github.com/plotly/dash-renderer/pull/100/). [#523](https://github.com/plotly/dash-core-components/pull/523/)


updated, or fixed? Perhaps "improved" since it's a little of each I guess.

👍 for improved, or we could have two categories in release log: 1 bug fix 2 feature enhancement

alexcjohnson · 2019-04-13T22:16:36Z

src/components/Input.react.js

@@ -62,7 +62,7 @@ export default class Input extends Component {
                    if (setProps) {
                        const payload = {
                            n_blur: this.props.n_blur + 1,
-                            n_blur_timestamp: new Date(),
+                            n_blur_timestamp: new Date.now(),


This is a breaking change #467 - yes, we should do it, but we should call it out.

alexcjohnson · 2019-04-13T22:21:32Z

src/components/Input.react.js

+    debounce: PropTypes.oneOfType([
+        PropTypes.string,
+        PropTypes.bool
+    ]),


What's string for here? Describe it in the docstring?

^^ applies to a bunch of these where either string or bool now accepts either... it's not clear to me which strings do what, or if they all evaluate to booleans or do something else entirely.

this one was wrong actually - only bool. But for the other HTML boolean properties, HTML5 defines the only accepted values as the name of the attribute (case insensitive) or "": https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attributes

That is, for autoFocus, the following assignments mean "turn on autofocus": autoFocus="", autoFocus="autoFocus", autoFocus="autofocus", autoFocus="AUTOFOCUS"

And in order for it to be "turned off", it has to be omitted.

It seems like browsers are a little more loose and they evaluate these strings to be "If it's supplied, then it's applied" - it doesn't need to be the name of the attribute. This ends up being confusing because checked="false" is actually "turn on checked" because it's applied. MDN says:

To be clear, the values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether. This restriction clears up some common misunderstandings: With checked="false" for example, the element’s checked attribute would be interpreted as true because the attribute is present.

So, we could either:

Just keep it as a string and allow users to navigate this spec. Move on for now and revist later.

Provide a preference but allow all strings: autoFocus: oneOfType([oneOf(['autoFocus', 'autofocus', '']), propTypes.string])

Be more opionated and only include the common forms like 'autoFocus': oneOf(['', 'autoFocus', 'autofocus', 'AUTOFOCUS']) but omit the other permutations like auToFoCus that are technically valid.

Be even more opinionated and only include the most sane-looking version: autoFocus='autoFocus' and omit the other versions that are technically valid.

I think I prefer 2 or 3

So does false (not 'false') turn autoFocus off? Or is None -> null the only value that disables it?

If this check is only applied in dev mode, I'd vote to be more opinionated - (3) seems reasonable, plus false if that's allowed to disable. I'd omit '' unless it's particularly common usage, as explicitly allowing a normally falsy value to mean true is bound to cause confusion. Either way we should document a recommended value, something like:

autoFocus is enabled by 'autoFocus', but alternate capitalizations 'autofocus' and 'AUTOFOCUS' are also accepted.

I thought that false ended up getting rendered as 'false' looks like I'm wrong about that:

(https://codepen.io/chriddyp/pen/MREmpK?editors=0010)

Similarly in our toolchain:

import dash import dash_html_components as html import dash_core_components as dcc app = dash.Dash(__name__) app.layout = html.Div([ dcc.Input(id='1', readOnly=True), dcc.Input(id='2', readOnly=False), dcc.Input(id='3', readOnly='readonly'), dcc.Input(id='4', readOnly='readOnly'), dcc.Input(id='5', readOnly='true'), dcc.Input(id='6', readOnly='false'), dcc.Input(id='7', readOnly=''), dcc.Input(id='8', readOnly='""'), ]) if __name__ == '__main__': app.run_server(debug=True)

#7 is pretty confusing - to get "" into the DOM, you have to pass in '""' not ''

So I suppose we could allow boolean for these properties as well.

Oy, 7 is insane, definitely do not allow any version of that! So yeah, true, false, and a couple of capitalizations of autoFocus.

a small section about the attributes in dash-docs might be necessary given all the experiments we have, as most of our audiences are not Frontend expert, we should align the preference in the demo code too

chriddyp · 2019-04-15T21:23:45Z

.circleci/config.yml

@@ -27,7 +27,7 @@ jobs:
                name: Install dependencies (dash)
                command: |
                    git clone [email protected]:plotly/dash.git
-                    git clone [email protected]:plotly/dash-renderer.git
+                    git clone --branch chriddyp-dev-tools [email protected]:plotly/dash-renderer.git


I'll remove this before merging. Just making sure that the other repo's prop checking doesn't cause these tests to fail.

byronz · 2019-04-16T02:30:44Z

src/components/Input.react.js

@@ -162,19 +162,30 @@ Input.propTypes = {
    /**
     * This attribute indicates whether the value of the control can be automatically completed by the browser.
     */
-    autocomplete: PropTypes.string,
+    autoComplete: PropTypes.string,


yes, given the complexity of autoComplete, I think string is a good compromise for now

chriddyp · 2019-04-17T05:26:52Z

Alright, this is passing with the dev-tools branch now 🎉 .

Had to make a fix to ConfirmModal so that it was idempotent, see 8b64f2d
.exact didn't have a proper docstring. This docstring was pretty nice for the long list of properties in Graph.config, so I added support for exact in the component generation in support exact just like shape dash#692
.exact also wasn't supported in the current version of react-docgen - upgrading to 3.0.0 fixed the issue.

byronz

💃

chriddyp · 2019-04-18T04:40:09Z

weird dateformat diff. 05/03/1997 vs 1997-05-03

chriddyp · 2019-04-18T04:40:37Z

that's the only error left

chriddyp · 2019-04-18T16:01:26Z

Odd - the new screenshots match the date supplied exactly. We send dt_input_1.send_keys("1997-05-03") and it appears exactly as "1997-05-03" instead of getting reformatted as 05/03/1997.

Odd that this behaviour would change in this PR. Looking into it...

- boolean props - can be bools or strings, right? - number props - can be numbers or stringified numbers, right?

no way to specify that the values of an object need to be a certain type if the object has arbitrary key names.

this matches the other date properties most notably `n_clicks_timestamp`

chriddyp · 2019-04-18T17:51:36Z

OK - I've isolated the issue. There seems to be a problem with dash-renderer's setProps not re-rendering the component with the correct prop types if an ID is not supplied. I'll look into dash-renderer next.

chriddyp · 2019-04-18T17:54:07Z

Here's a reproducable example that shows the issue (try editing the dates). I'll work on a fix in dash-renderer now.

from datetime import datetime as dt
import dash
import dash_html_components as html
import dash_core_components as dcc

app = dash.Dash(__name__)

app.css.config.serve_locally = True
app.scripts.config.serve_locally = True

app.layout = html.Div([
    html.Div([
        html.Label('With ID'),
        dcc.DatePickerSingle(id='date-picker-with-id'),
    ]),

    html.Div([
        html.Label('Without ID'),
        dcc.DatePickerSingle(),
    ])

])


if __name__ == '__main__':
    app.run_server(debug=True, dev_tools_hot_reload=False)

as we’re not holding the date in state anymore

byronz reviewed Apr 12, 2019

View reviewed changes

src/components/Input.react.js Outdated Show resolved Hide resolved

byronz reviewed Apr 12, 2019

View reviewed changes

src/components/Input.react.js Outdated Show resolved Hide resolved

alexcjohnson reviewed Apr 12, 2019

View reviewed changes

src/components/RangeSlider.react.js Outdated Show resolved Hide resolved

alexcjohnson reviewed Apr 13, 2019

View reviewed changes

chriddyp commented Apr 15, 2019

View reviewed changes

byronz reviewed Apr 16, 2019

View reviewed changes

chriddyp mentioned this pull request Apr 17, 2019

support exact just like shape plotly/dash#692

Merged

byronz approved these changes Apr 18, 2019

View reviewed changes

chriddyp added 11 commits April 18, 2019 12:12

label & value are required in options

f2e648e

extend data is an array i think?

6f6d4f4

simple figure validation

c1aae29

html property handling

d7687ac

- boolean props - can be bools or strings, right? - number props - can be numbers or stringified numbers, right?

marks prop type was wrong

e49da69

no way to specify that the values of an object need to be a certain type if the object has arbitrary key names.

objectOf to the rescue

f7265c7

fix properties that weren't camelCase & update boolean props

59031e7

slightly more specific figure definition

e9cb3d8

📝 changelog

5bfa025

date number not date object

bd6d771

this matches the other date properties most notably `n_clicks_timestamp`

📝 include note about n_blur_timestamp fix

50ca713

byron and others added 5 commits April 18, 2019 12:12

🔧 change back to master

ca52b21

💄 prettier

7191fe4

extendData takes an array or an object

599daeb

hide dev_tools_ui for tests so that screenshots are the same

98c8794

prettier

41a3f31

chriddyp force-pushed the fix-prop-types branch from 3c4409a to 41a3f31 Compare April 18, 2019 16:13

chriddyp mentioned this pull request Apr 18, 2019

WIP - R dbg #531

Closed

chriddyp mentioned this pull request Apr 18, 2019

support datepickersingle as an uncontrolled component #532

Merged

chriddyp and others added 16 commits April 19, 2019 23:17

support datepickersingle as an uncontrolled component

96fc7b6

similar fix for DatePickerRange

0f04a50

include link to dash-renderer issue

2ffefb6

just include ids in props for now

92799ac

🔪

55d15dd

rm state checks for dates

b526f98

as we’re not holding the date in state anymore

prettier

fc6c6d7

🙇 thanks @byronz

93e2f01

🐛 fixing the onDataChange logic

2081efb

💄 prettier

a116ec4

✅ fix test

18f0a17

🔪 🐛 fix the bug and improve the test

b5a06fe

📦 bundles

c416812

✅ every month has at least 28

ca47915

💄 prettier

8e1475a

💄 flake8

d7851a1

byronz merged commit fecc76e into master Apr 20, 2019

byronz deleted the fix-prop-types branch April 20, 2019 03:30

alexcjohnson mentioned this pull request Apr 20, 2019

Fix setProps when IDs aren't provided plotly/dash-renderer#166

Merged

Marc-Andre-Rivet mentioned this pull request Aug 8, 2019

Input component property "maxlength" does not work #505

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix prop types #523

Fix prop types #523

chriddyp commented Apr 12, 2019

chriddyp commented Apr 12, 2019

byronz commented Apr 12, 2019

chriddyp commented Apr 13, 2019 •

edited

Loading

chriddyp commented Apr 13, 2019

chriddyp commented Apr 13, 2019

alexcjohnson Apr 13, 2019

byronz Apr 15, 2019

alexcjohnson Apr 13, 2019

alexcjohnson Apr 13, 2019

alexcjohnson Apr 13, 2019

chriddyp Apr 14, 2019 •

edited

Loading

chriddyp Apr 14, 2019

alexcjohnson Apr 14, 2019

chriddyp Apr 14, 2019

alexcjohnson Apr 14, 2019

byronz Apr 15, 2019

chriddyp Apr 15, 2019

byronz Apr 16, 2019

chriddyp commented Apr 17, 2019

byronz left a comment

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

Fix prop types #523

Fix prop types #523

Conversation

chriddyp commented Apr 12, 2019

chriddyp commented Apr 12, 2019

byronz commented Apr 12, 2019

chriddyp commented Apr 13, 2019 • edited Loading

chriddyp commented Apr 13, 2019

chriddyp commented Apr 13, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chriddyp Apr 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chriddyp commented Apr 17, 2019

byronz left a comment

Choose a reason for hiding this comment

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

chriddyp commented Apr 18, 2019

chriddyp commented Apr 13, 2019 •

edited

Loading

chriddyp Apr 14, 2019 •

edited

Loading