-
Notifications
You must be signed in to change notification settings - Fork 33
Conversation
bfce911
to
cfe4c40
Compare
if (r.status === 'loading' && contains(id, r.controllerId)) { | ||
isLoading = true; | ||
loadingComponent = r.controllerId.split('.')[0]; | ||
loadingProp = r.controllerId.split('.')[1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can split only one time: [loadingProp, loadingComponent] = r.controllerId.split('.')
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the most appropriate would be a .forEach()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
} | ||
}); | ||
|
||
const thisRequest = requestQueue.filter(r => contains(id, r.controllerId)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The filter is here.
Would like to see the following issues opened as follow ups:
|
As discussed with @valentijnnieman, we are currently going for a mixed approach, supporting both
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 |
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 So, if my understanding is right, the existing code is Code reference: dash-renderer/src/actions/index.js Line 328 in ed06794
Connected dash-renderer/src/components/core/NotifyObservers.react.js Lines 7 to 105 in ed06794
|
@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. |
… loading_states_api
Released as prerelease version |
There seems to be an issue here that's causing the |
Published |
Released as prerelease version |
@@ -2,6 +2,9 @@ | |||
All notable changes to this project will be documented in this file. | |||
This project adheres to [Semantic Versioning](http://semver.org/). | |||
|
|||
## [0.18.0] - 2019-01-30 | |||
### Added | |||
- Loading states API [#267](https://github.com/plotly/dash/issues/267) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For final merge, needs to be unreleased and version bump reverted in package.json
src/TreeContainer.js
Outdated
return nextProps.layout !== this.props.layout; | ||
return ( | ||
nextProps.layout !== this.props.layout | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Here's the first pass at a loading states api, where
dash-renderer
now provides aloading_state
prop to components that are taking some time to load. It is used with a dist of this PR that provides aLoading
component, that can wrap any other Dash component, making it display a loading spinner if it's not fully rendered.An example is included insimple.py
, make sure to install thedev-requirements.txt
before running it!TODO:
The
loading_state
prop is an object that looks like: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 examplechildren
).Community post: https://community.plot.ly/t/loading-states-api-and-a-loading-component-prerelease