No events

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃

[alexcjohnson]

Closes#433 - last in the series for plotly/dash#531

In addition, as in the other no-events PRs, I tried to unify the local and CI test runners, and make it so on CI all tests run, even if an earlier one fails, so you get a complete failure report - see 3f0b9df, @T4rk1n@Marc-Andre-Rivet are you comfortable with this?

[alexcjohnson]

@T4rk1n the dcc css test:

dash-core-components/test/test_integration.py

Lines 1421 to 1429 in 674fd07

	deftest_user_supplied_css(self):
	app=dash.Dash(assets_folder='test/assets')
	app.layout=html.Div(className="test-input-css", children=[dcc.Input()])
	self.startServer(app)
	self.wait_for_element_by_css_selector('.test-input-css')
	self.snapshot('styled input - width: 100%, border-color: hotpink')

is failing, seems to be due to plotly/dash#547 - can you take a look at it, see if it's just the test that needs updating or if there's a real issue with the new assets_folder logic? The same issue that percy caught in this PR, that the extra css is not showing up, I see it locally running this test both on master and on this branch.

[alexcjohnson]

the dcc css test is failing, seems to be due to plotly/dash#547

OK yeah, that was an easy fix, and after looking at it in a little more detail, that test was definitely locking down buggy behavior!

[Marc-Andre-Rivet]

I do so love this package 🥇

[Marc-Andre-Rivet]

• Interval tests still contain fireEvent logic
• Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

[Marc-Andre-Rivet]

Can you confirm what version of dash is used in your environment during the components py file generation? I have 0.35.3 locally and I'm getting a significant amount of diffs vs. what's in the PR. By default, this is running on Python 3.7 in my environment -- don't know if it should makes a difference.

[Marc-Andre-Rivet]

Test run in dash-docs seems to be behaving fine. Once the ☝️ are fixed I'm fine with this PR.

[alexcjohnson]

Can you confirm what version of dash is used in your environment during the components py file generation?

Right, this needs to be built off the no-events branch of dashplotly/dash#550. Also I believe it needs to be built with py3 (which you're doing anyway) since that branch doesn't yet have @rpkyle's byteify fix from plotly/dash#545

[T4rk1n]

Can combine them with python -m unittest discover

[alexcjohnson]

Ah good to know! But test_dash_import is funny, since it rewrites files (specifically, making a dash.py in the test folder) you can't run it in conjunction with any of the other tests. So if we wanted to use discover we'd have to make test_dash_import undiscoverable one way or another, and still run it separately.

[T4rk1n]

Hmm, that test is strange, not sure we really need to test that.

[alexcjohnson]

I guess someone put that error message in the code, so they wanted to see it in a test. But yeah, not the most useful test to be lugging around.

[alexcjohnson]

Interval tests still contain fireEvent logic

Ah good call, that came in with a community PR after my initial sweep through the code... fixed in 7d82256

Technically out of scope, but while updating the test scripts, could you change npm's lint command to do eslint src test instead of just src -- and fix the associated lint errors

Sure, easy enough -> 948c7dc

[T4rk1n]

😺 This addition of props should be noted somewhere, had to read the code to see it.

[alexcjohnson]

Thanks @T4rk1n -> added to CHANGELOG in 8b4936b

Kind of amazing that these two are the only events we had that weren't covered by an existing regular prop already.

[Marc-Andre-Rivet]

Looks good to me. Maybe @T4rk1n will have additional insight.

[T4rk1n]

💃