Support for wildcard attributes, implement data-* attribute by rmarren1 · Pull Request #237 · plotly/dash

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 · 2018-03-30T03:07:03Z

Adds the data-* html attributes, like so:

>>> import dash_html_components as html
>>> html.Div(id="my-id", **{'data-foo': 'foo', 'data-bar': 'bar'})
Div(id='my-id', data-foo='foo', data-bar='bar')

Tested using Tox, however I

removed the python -m unittest tests.test_react test, since this is broken in Tox tests fail on master branch #236 and Events are broken; base_component.parse_events needs updating #232
added the python -m unittest tests.development.test_base_component and python -m unittest tests.development.test_component_loader tests, since only running tox was not causing these tests to run (or are are these tests generally invoked in another way?)

chriddyp · 2018-04-03T14:08:33Z

+ List of Dash valid wildcard prefixes
+ """
+ list_of_valid_wildcard_attr_prefixes = []
+ for wildcard_attr in ["data-*"]:


I suppose "aria-*" too

chriddyp · 2018-04-03T14:27:16Z

This looks great, thanks @rmarren1 !

Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
- In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
- In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
html.Div(
id='data-element',
**{
'data-string': 'multiple words',
'data-number': 512,
'data-none': None,
'data-date': datetime.datetime(2012, 1, 10),
'aria-progress': 5
}
)
])
self.startServer(app)
div = self.wait_for_element_by_id('data-element')
self.assertEqual(
div.get_attribute('innerHTML'),
(
'<div id="data-element" '
'data-string="multiple words" '
'data-number="512" '
'data-none=""'
'data-date="2012-01-10"
'aria-progress="5"'></div>'
)

Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

Edit: Added aria-progress to the test example

chriddyp · 2018-04-03T14:57:24Z

I've published a prerelease version at pip install dash==0.22.0rc1

chriddyp · 2018-04-03T15:35:15Z

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

rmarren1 · 2018-04-04T19:03:40Z

plotly/dash-html-components#40
plotly/dash-renderer#52

rmarren1 · 2018-04-04T19:07:51Z

+ **{
+ 'data-string': 'multiple words',
+ 'data-number': 512,
+ 'data-none': None,


This value will not be rendered in the html div.

rmarren1 · 2018-04-04T19:12:27Z

Test is dependent on changes in plotly/dash-html-components#40

claresloggett · 2018-04-07T06:06:47Z

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

chriddyp · 2018-04-07T18:28:05Z

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

chriddyp · 2018-04-09T18:20:29Z

+ # Add the wildcard properties data-* and aria-*
+ props.update({
+ k: getattr(self, k)
+ for k in self.__dict__


ah, way better 👍

chriddyp · 2018-04-09T18:21:59Z

+ 'id': 'a',
+ },
+ 'type': 'MyComponent'}
+ )


chriddyp · 2018-04-09T18:22:52Z

+
+ input_call_count = Value('i', 0)
+
+ @app.callback(Output('output-1', 'data-cb'), [Input('input', 'value')])


very cool that this works

chriddyp · 2018-04-09T18:26:24Z

Very, very nice @rmarren1 🎉

I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.
Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

rmarren1 · 2018-04-10T20:59:39Z

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

chriddyp · 2018-04-11T19:24:55Z

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

rmarren1 · 2018-04-11T20:45:11Z

I'm good with it, go ahead!

kmader · 2018-04-16T16:17:07Z

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

rmarren1 · 2018-04-19T13:54:23Z

I needed dash==0.22.0rc2

claresloggett · 2018-05-06T12:53:09Z

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

ned2 · 2018-05-06T13:18:22Z

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

rmarren1 · 2018-05-06T13:42:37Z

Try dash-html-components==0.11.0rc5 dash==0.21.1

claresloggett · 2018-05-07T05:42:02Z

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171

…tly#237)

rmarren1 mentioned this pull request Mar 30, 2018
Added data-* and aria-* attributes plotly/dash-html-components#40
Merged

chriddyp reviewed Apr 3, 2018
View reviewed changes

rmarren1 added 2 commits April 4, 2018 09:47

data-* and aria-* attribute support, with serialization
08f6263

edit callback validator for * attrs and a integration test
8f2d3c2

rmarren1 force-pushed the master branch from 17a0e5b to 8f2d3c2Compare April 4, 2018 18:53

rmarren1 commented Apr 4, 2018
View reviewed changes

Tests for data-* aria-* docgen, repr
54c9ef5

chriddyp reviewed Apr 9, 2018
View reviewed changes

Comment threadtests/development/test_base_component.py
'id': 'a',
},
'type': 'MyComponent'}
)
chriddypApr 9, 2018
Copy link
Copy Markdown
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍

chriddyp reviewed Apr 9, 2018
View reviewed changes

rmarren1 added 2 commits April 10, 2018 16:21

fixed linting issues and date-time issue with testing
ec666eb

updated changelog.md and version.py
a4bb578

chriddyp merged commit 3dfa941 into plotly:masterApr 23, 2018

chriddyp mentioned this pull request Jun 8, 2018
Any planned support for data* or aria-* options? #78
Closed

HammadTheOne pushed a commit to HammadTheOne/dash that referenced this pull request May 28, 2021
Issue 235 - Fix regressions introduced to PyPi and NPM packaging (plo…
8594438
…tly#237)

HammadTheOne pushed a commit that referenced this pull request Jul 23, 2021
Issue 235 - Fix regressions introduced to PyPi and NPM packaging (#237)
3def701

vogloblinsky mentioned this pull request Feb 23, 2022
Support for wildcard data-* attribute dbc-team/dash-bootstrap-components#817
Closed

AnnMarieW mentioned this pull request May 4, 2024
dash component generation doesn't work for hyphenated props #2843
Open

alexcjohnson mentioned this pull request Sep 26, 2024
dmc.Collapse - required parameter in does not work snehilvj/dash-mantine-components#305
Closed