Loading states api

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.

[valentijnnieman]

Here's the first pass at a loading states api, where dash-renderer now provides a loading_state prop to components that are taking some time to load. It is used with a dist of this PR that provides a Loading component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered. An example is included in simple.py, make sure to install the dev-requirements.txt before running it!

TODO:

• Include which property is loading. Currently we strip the component's name, but it also includes the property that's loading, so we could pass that down as well.
• Clean-up!

The loading_state prop is an object that looks like:

{
is_loading: bool,
component_name: string,
prop_name: string
}

So that component authors can determine when to show a loading spinner, and know which component in the chain caused the loading to happen (it will return the id of the component), and which prop is loading (for example children).

Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease

[chriddyp]

For those following along in the community, here's a demo:

[T4rk1n]

Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.').

[T4rk1n]

Had a hard time figuring this out, that is not a proper map. It should be a for loop or a filter or a find.

[nicolaskruchten]

the most appropriate would be a .forEach()

[rmarren1]

We have been using rambda elsewhere in dash-renderer even when a core javascript function exists for a task, so https://ramdajs.com/docs/#forEach would fit better

[T4rk1n]

The filter is here.

[Marc-Andre-Rivet]

Would like to see the following issues opened as follow ups:

• enabling direct support of loading state in DCC components (loading_state + animation type)
• integration testing support for dash-renderer (our tests are all at the behavioural / dash server level atm) -- test loading states, test loading states transition, test more complex graph shapes (Loading component with multiple children, Loading comp within a parent loading comp)
• removing the 'Loading...' from dash.py

[Marc-Andre-Rivet]

As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both

• loading state as a data-attribute on the components + styleguide / css styling of loading comps
• Loading component with 1 level deep loading_state support -- the user becomes responsible for putting items that are actually slow to load (e.g. no listening to children prop in Dash)

While the updated implementation looks promising, my main concern right now has to do with the mechanics of getting this to work -- the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state -- the queue is impacted by user actions and changes often during back-and-forth with Dash. Since not all components are pure in html and dcc, or protected by a componentShouldUpdate method, this may cause a significant performance impact. This should be studied and minimized before the feature can be released / sent back for community testing. It's possible that the impact will be negligible but if not, we may have to expose the queue data differently so as to not trigger useless re-render.

[chriddyp]

the TreeContainer or the NotifyObserver needs to be hooked up to the store's requestQueue through a prop in order to determine the component's state

I'm a little rusty on the redux details here, but I thought that any dispatch that happens will trigger an update. I don't believe that there isn't anything in NotifyObservers that says "If store.x changes, then update. But if store.y changes, don't update.". Does this match your understanding too or am I forgetting about something? If so, can you point me to the code where this happens?

So, if my understanding is right, the existing code is dispatching to update the request queue which is already cause re-rendering. Passing new props through in NotifyObserversComponent shouldn't change this.

Code reference: dispatch(setRequestQueue(

dash-renderer/src/actions/index.js

Line 328 in ed06794

dispatch(setRequestQueue(concat(requestQueue,newRequestQueue)));

Connected NotifyObservers

dash-renderer/src/components/core/NotifyObservers.react.js

Lines 7 to 105 in ed06794

	/*
	* NotifyObservers passes a connected `setProps` handler down to
	* its child as a prop
	*/
	functionmapStateToProps(state){
	return{
	dependencies: state.dependenciesRequest.content,
	paths: state.paths,
	};
	}
	functionmapDispatchToProps(dispatch){
	return{dispatch};
	}
	functionmergeProps(stateProps,dispatchProps,ownProps){
	const{dispatch}=dispatchProps;
	return{
	id: ownProps.id,
	children: ownProps.children,
	dependencies: stateProps.dependencies,
	paths: stateProps.paths,
	setProps: functionsetProps(newProps){
	constpayload={
	props: newProps,
	id: ownProps.id,
	itempath: stateProps.paths[ownProps.id],
	};
	// Update this component's props
	dispatch(updateProps(payload));
	// Update output components that depend on this input
	dispatch(notifyObservers({id: ownProps.id,props: newProps}));
	},
	};
	}
	functionNotifyObserversComponent({
	children,
	id,
	paths,
	dependencies,
	setProps,
	}){
	constthisComponentSharesState=
	dependencies&&
	dependencies.find(
	dependency=>
	dependency.inputs.find(input=>input.id===id)||
	dependency.state.find(state=>state.id===id)
	);
	/*
	* Only pass in `setProps` if necessary.
	* This allows component authors to skip computing unneeded data
	* for `setProps`, which can be expensive.
	* For example, consider `hoverData` for graphs. If it isn't
	* actually used, then the component author can skip binding
	* the events for the component.
	*
	* TODO - A nice enhancement would be to pass in the actual
	* properties that are used into the component so that the
	* component author can check for something like
	* `subscribed_properties` instead of just `setProps`.
	*/
	constextraProps={};
	if(
	thisComponentSharesState&&
	// there is a bug with graphs right now where
	// the restyle listener gets assigned with a
	// setProps function that was created before
	// the item was added. only pass in setProps
	// if the item's path exists for now.
	paths[id]
	){
	extraProps.setProps=setProps;
	}
	if(!isEmpty(extraProps)){
	returnReact.cloneElement(children,extraProps);
	}
	returnchildren;
	}
	NotifyObserversComponent.propTypes={
	id: PropTypes.string.isRequired,
	children: PropTypes.node.isRequired,
	path: PropTypes.array.isRequired,
	};
	exportdefaultconnect(
	mapStateToProps,
	mapDispatchToProps,
	mergeProps
	)(NotifyObserversComponent);

[Marc-Andre-Rivet]

@chriddyp No, your understanding seems to be correct. Adding the prop from the store does not have the impact I thought it would have. My thinking was that since N.Obs. had a new prop from the store, that would trigger extra renders but that assumption was incorrect. There are a few extra renders in the observer when first starting the app but after that it's a one to one match with previous behavior.

Thanks for the input.

[valentijnnieman]

Released as prerelease version 0.18.0rc1.

[valentijnnieman]

There seems to be an issue here that's causing the test_confirm_as_children in dash-core-components to fail. Haven't been able to figure this out yet.

[valentijnnieman]

Published 0.18.0rc3 which should fix some of the tests in DCC failing.

[valentijnnieman]

Released as prerelease version 0.18.0rc4

[Marc-Andre-Rivet]

For final merge, needs to be unreleased and version bump reverted in package.json

[Marc-Andre-Rivet]

Is checking only for the layout enough to update correctly in all cases? How does this cover the requestQueue updates? Or how is the requestQueue not necessary?

[valentijnnieman]

I'm not sure about this. The main reason that I haven't added any nextProps.requestQueue checks is that it causes tests to fail. I'm guessing that re-rendering upon differences in the requestQueue prop causes some behaviour to be different - I'm seeing test_radio_buttons_callbacks_generating_children and test_hot_reload tests failing.