Dont clone figure.layout

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)

[almarklein]

Fixes#879 (hopefully)

This small changes fixes the issue (for e.g. the example below). That said, I cannot oversee whether this potentially breaks other code. In theory, the tests will tell ;)

Example to test this:

importdashimportdash_html_componentsashtmlimportdash_core_componentsasdccfromdash.dependenciesimportInput, Output, Stateapp=dash.Dash(__name__, update_title=None)
fig= {"data": [], "layout": {"dragmode": "drawrect"}}
graph=dcc.Graph(id="graph", figure=fig)
app.layout=html.Div(
[
graph,
html.Br(),
html.Button(id='button', children="Clone figure"),
html.Div(id='output', children=""),
]
)
app.clientside_callback(
"""function clone_figure(_, figure) { let new_figure = {...figure}; let shapes = new_figure.layout.shapes || []; return [new_figure, shapes.length]; } """,
[Output("graph", "figure"), Output("output", "children")],
[Input("button", "n_clicks")],
[State("graph", "figure")],
)
if__name__=="__main__":
app.run_server(debug=True)

[almarklein]

Mmm, there seems to be a problem with CI in general.

[alexcjohnson]

hmm, not sure what's going on with CI, I'll have to investigate.

We're going to need to do more than just dropping the getLayout step though - check out what happens in there with responsive and how it modifies autosize, height, and width.

In principle we may need to save the original values of these attributes in state, so cases where the user provides a figure and then later changes the responsive prop without changing the figure itself we can bring those original values back as needed. In practice though I doubt users change responsive much.

[alexcjohnson]

Mmm, there seems to be a problem with CI in general.

The dash-html-components build process broke. I'm investigating and will update you when it's resolved.

[alexcjohnson]

Fixed the build process via plotly/dash-html-components#170 - now it's just routine linter errors 😏

[almarklein]

Updated, and tests added. Only a linting issue with prettier. Unfortunately, it does not show what is wrong, and I cannot reproduce the linting locally (and I do not see any obvious errors).

[almarklein]

I also updated the code sample in the top post to do about the same thing as the test does.

[alexcjohnson]

eb82ae1 resulted from npm run format (fixed the prettier issues), but also for some reason locally I needed to update the __init__.py before the pre-commit hooks would pass. 🤷

[almarklein]

Updated again.

I also ran a little test with a layout that has width and height set to 300. The figure is originally this small size. Turning responsive to true will make the figure span the available space (and width and height are undefined). Turning responsive off again resets the figure to its original small size.

[almarklein]

The failing test looks like a glitch in another test.

[emmanuelle]

I restarted the CI and all looks good now.

[almarklein]

@alexcjohnson also added a test to check that original values are correctly restored.

[emmanuelle]

Hi, any chance to get this PR merged before the next Dash release? Pretty please :-) ?

[alexcjohnson]

Yes sorry, it's been waiting on me to play with it a bit, but we'll get it in for the next release.

[alexcjohnson]

OK! @almarklein I was concerned about how this would work in various other cases including both mutations and brand new figures and alternating responsive and figure edits, so I expanded on your second test a bit. All works great! 💃

[almarklein]

Thanks @alexcjohnson for wrapping this one up :)