Issue 481 - Support arbitrary file extensions in component suites

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃

[Marc-Andre-Rivet]

Closes#481

Add arbitrary file support for component suite.

This is being done with the idea of packaging fonts with the components that require them without the need for adding assets or loading everything upfront as base64 inside css files. Images would be handled similarly, also with the file-loader.

Once added, component repos using webpack can use the following loader configuration:

{
test: /\.(woff|woff2|eot|svg|ttf)$/,
use: [{
loader: 'file-loader',
options: {
limit: 0, // no resource gets inlined in the js bundle
esModule: false, // this option is required for file-loader >= 5.0.0
name: '[name].[ext]'
}
}]
}

And include source resources in css files like so:

@font-face {
font-family: 'My-Font';
src: url(./My-Font.ttf) format('truetype');
}

url(./My-Font.ttf) will be resolved to the correct path by the same plugin used for async (https://github.com/plotly/dash/tree/dev/%40plotly/webpack-dash-dynamic-import)

And include the resource in the component's __init__.py (and MANIFEST):

{
'relative_package_path': 'My-Font.ttf',
'external_url': (
'https://unpkg.com/my-dash-components@{}'
'/my_dash_component/My-Font.ttf'
).format(__version__),
'namespace': 'my_dash_component',
'dynamic': True
},

Adding dynamic:True will ensure that the file is only loaded when requested by the css (e.g. async scenarios).

Do note that as implemented, these resources will not be fingerprinted and will default to using eTag for caching purposes.

[wbrgss]

@Marc-Andre-Rivet Using his branch for my Dash installation (and re-running dash-generate-components, but this step doesn't seem to affect the result) results in my component not being able to load its raw _css_dist files, e.g those enumerated in

_css_dist = [
{
"relative_package_path": "main.css",
"namespace": "my_component"
},
{
"relative_package_path": "style1.css",
"namespace": "my_component"
},
{
"relative_package_path": "style2.css",
"namespace": "my_component"
},
{
"relative_package_path": "etc.css",
"namespace": "my_component"
},
...
]

When switching back to the released Dash 1.8.0, these CSS files are loaded OK. Assets and css-in-js seem to load fine in either changeset.

When testing this branch, I expected everything to be loaded as before, except for my font files. Is it possible I need to modify my webpack config and __init__.py in order to have backwards compatibility with my normal _css_dist files? Even if I'm doing something wrong in my component config, I'm worried about component authors upgrading Dash and seeing a breaking change in that their _css_dist*.css files are no longer appearing.

[wbrgss]

This PR is closer than I thought; I can load custom fonts. The CSS and JS files are being loaded too, but the CSS is not being applied as per #1078 (comment). That is, the rules are not being applied to the elements they select, even though the CSS files are there.

[Marc-Andre-Rivet]

@wbrgss Fixed some issues - can you give it another go?

.css files were loaded as application/octet-stream instead of text/css

[Marc-Andre-Rivet]

Pick up everything but the Python artifacts

[alexcjohnson]

Is this better than dash.testing.wait.until? It's barely any more complicated so fine to keep it, just curious if there's a difference.

Regardless, very nice test!

[Marc-Andre-Rivet]

Wasn't aware I could do that. I thought it was either this of dash_duo._wait_for, will keep in mind for the future.

[alexcjohnson]

💃