Graph dimension problem with dcc.Loading — regression (?) in DCC 1.9.1

[wbrgss]

Given a certain layout (I've tried to trim down to a minimal example as best I can), dcc.Loading causes its dcc.Graph children to not obey their set heights in CSS.

In the below examples, I expect the Graph to be constrained within the purple boundary.

With the code below, with Dash 1.11.0 and Dash Core Components 1.9.1:

With Dash 1.11.0 and Dash Core Components 1.9.0 (or simply Dash <= 1.10.0):

Unfortunately, there was one rule I had to put in an /assets/style.css, I left a comment in the app.

app.py

import dash
import dash_html_components as html
import dash_core_components as dcc

app = dash.Dash(__name__)

app.layout = html.Div(
    children=[
        # this outer div is necessary to reproduce
        html.Div(
            dcc.Loading(
                # This must load CSS from an external file
                # in /assets via the className
                # style={"height": "100%"} won't have the same effect
                className="loading-container",
                children=dcc.Graph(
                    style={"height": "100%"},
                    figure={
                        'data': [{
                            'x': [1, 2, 3, 4],
                            'y': [4, 1, 6, 9],
                            'line': {'shape': 'spline'}
                        }]
                    }
                ),
            ),
        )
    ],
    style={
        # these rules are necessary to reproduce
        "display": "flex",
        "maxHeight": "30vh",
        # the below two rules are for visual demo purposes
        "padding": "15px",
        "background": "purple"
    },
)

if __name__ == "__main__":
    app.run_server(debug=True)

style.css

.loading-container {
    height: 100%;
}

[wbrgss]

My guess is that this is coming from #740. If you replace the dcc.Loading with an html.Div in the example above, the problem goes away. I welcome @alexcjohnson to take a look at this please, as you recently got your hands dirty with graph dimensions, and it looks like you were the main reviewer on/a contributor to #740 🙂

[wbrgss]

Some more details after some investigation:

  # This must load CSS from an external file
  # in /assets via the className
  # style={"height": "100%"} won't have the same effect

The reason or this is that dcc.Loading doesn't seem to add inline styles on its outermost container when it's given a style prop, even though it accepts this prop. It adds the inline styles on the Spinner component but not on the outermost container, and in a nested layout like this all of the containers in the hierarchy need to have e.g. height: inherit or height: 100%. The empty style object on the outermost div (that gets the conditional hiddenContainer style) here breaks that chain:

dash-core-components/src/components/Loading.react.js

Lines 41 to 62 in 1e9abb7

	render() {
	const {
	loading_state,
	color,
	className,
	style,
	fullscreen,
	debug,
	type: spinnerType,
	} = this.props;
	const isLoading = loading_state && loading_state.is_loading;
	const Spinner = isLoading && getSpinner(spinnerType);
	return (
	<div style={isLoading ? hiddenContainer : {}}>
	{this.props.children}
	<div style={isLoading ? coveringSpinner : {}}>
	{isLoading && (
	<Spinner
	className={className}
	style={style}

Furthermore, in DCC 1.9.0, a className is applied to this div, so the /assets CSS works. But in >= 1.9.1, the className does not appear in the DOM, so the height: 100% is not applied, and this is the reason for the regression.

So IMO style and className should be applied to the outermost container, or (to avoid breaking changes and allow these props to be passed to the Spinner) we should give it props like parent_style and parent_className as discussed in a related issue re: prop nesting in the DOM here: #606

[chriddyp]

A community member reported issues when they upgraded here: https://community.plotly.com/t/percentage-height-of-dcc-loading-children/42222/2

So it seems like we should revert what className used to mean and then introduce a new parent_className or child_className for whatever the new(er) behavior is.

[jimhendy]

Hi,
It sounds like you have a fix for this issue. Will it be pulled soon?
Thanks

[jimhendy]

Hi @chriddyp & @wbrgss, sorry to bug you but can you please let us know the plan for this? This issue is stopping us updating which is becoming an increasing problem.
Thanks for your help