Dash Renderer 2.0 - **Breaking Changes**

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.

[chriddyp]

This is a work-in-progress proposal that would allow component authors to write components where any property (prop) is a Dash component, not just the children property.

This is handled by passing in a 3rd prop to the components: render. render should be used whenever a user-supplied property could be another Dash component. For example, the children property in the dash-html-components library is now rendered like:

<div>{this.props.render(this.props.children)}</div>

rather than simply

<div>
{this.props.children}
</div>

This allows the component author to allow the user to supply dash components as any property, for example, a RadioItems component could be composed like:

functionRadioItems(props){const{
value,
options,
setProps,
fireEvent,
render
}=props;return(<div>{options.map(option=>(<label><inputchecked={option.value===value}type="radio"onChange={()=>{this.setState({value: option.value});if(setProps)setProps({value: option.value});if(fireEvent)fireEvent({event: 'change'});}}/>{render(option.label)}</label>))}</div>)}

Notice how the label is now render(option.label). This allows the dash user to supply dash components inside their options.label property. Instead of just:

dcc.RadioItems(
options=[
{‘label’: ‘Item1’, ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

they could supply something like:

dcc.RadioItems(
options=[
{‘label’: html.Div(‘Item1’, style={‘color’: ‘cyan’}), ‘value’: 1},
{‘label’: ‘Item2’, ‘value’: 1}
]
)

This will allow a whole new level of customizability across all Dash components.

---

However, this introduces a 🆘breaking change 🆘. All of the component libraries will need to be upgraded to support this version of dash-renderer. Third-party component libraries will break if the user upgrades their dash-renderer. I’m not sure if there is a way around this (feature detection).

[chriddyp]

Prerelease versions are available with this code

pip install dash-core-components==0.16.0rc1
pip install dash-html-components==0.9.0rc1
pip install dash-renderer==0.13.0rc2
pip install dash-table-experiments==0.6.0rc1

[chriddyp]

😌 CircleCI tests are passing!

[chriddyp]

Getting some errors while trying to use these libraries in the dash-docs

[r-chris]

Any update on the time-line / stability of this to move forward?

We are ultimately interested in getting this: plotly/dash-table-experiments#11 (comment) to work down the track, so that this can become true: https://twitter.com/chriddyp/status/920146214062043136 ;)

Thanks by the way for this amazing project - we just started to switch from another plotting library a few months ago and it rocks!

[tcbegley]

hey @chriddyp, any idea how long it might be until this gets merged? Is there anything we could do to help you get it over the line?

[chriddyp]

Any idea how long it might be until this gets merged

This PR was experimental and it ends up affecting a huge part of the code base. We'll get there, but probably not for another few months at least. For now, we're focusing on improving the current state of the library through a few other projects: https://github.com/orgs/plotly/projects. Once those wind down, we'll have some more bandwidth to tackle these deeper architectural changes.

[tcbegley]

Cool, thanks for the update. The projects look great. Thanks for all your work on Dash, it’s an awesome library.

[alexcjohnson]

This PR is stale. #92 - which itself still needs a bunch more work - is the continuation of these ideas.