You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 4, 2024. It is now read-only.
The main complexity is the path store: we cache the path of components with an ID and have nice redux actions for updating the layout based off that path.
There might be two options here:
Keep track of the component path as we recurse through TreeContainer and use that path in our dynamic setProps construction.
Or, for components with no ID, auto-generated one based on the path. It’d effectively be for every component in the tree as we don’t know in advance if a component uses setProps or not. so there might be a memory impact for apps with tons of components. but it’d only be a fraction of the layout store (since we don’t need to save the other props). We already have logic flows for mutating the layout store (and updating paths) when components’ children get updated, so we could potentially mutate the layout store in those flows and inject a private ID prop. There’d be a little mismatch from what the backend provides and what is in the layout store, but might be do able.
A nice side effect of having paths for all components (not just those with IDs) would be to display the path of ID-less components. Here's where we display the ID if it's available.
(From plotly/dash-core-components#532)
In
dash-renderer
, we now providesetProps
for all components, regardless of whether they are connected to the backend.However, the
setProps
that we provide needs an ID in order for it to update the component:dash-renderer/src/TreeContainer.js
Lines 146 to 181 in 84c484b
We should provide a function
setProps
no matter what, even if the component doesn't have an ID. Otherwise, component authors will have to write logic like this: https://github.com/plotly/dash-core-components/pull/532/files#diff-2ee8e0d2935bbb7cda96c81810cf07eeThe main complexity is the
path
store: we cache the path of components with an ID and have nice redux actions for updating the layout based off that path.There might be two options here:
TreeContainer
and use that path in our dynamicsetProps
construction.setProps
or not. so there might be a memory impact for apps with tons of components. but it’d only be a fraction of the layout store (since we don’t need to save the other props). We already have logic flows for mutating the layout store (and updating paths) when components’ children get updated, so we could potentially mutate the layout store in those flows and inject a private ID prop. There’d be a little mismatch from what the backend provides and what is in the layout store, but might be do able.A nice side effect of having paths for all components (not just those with IDs) would be to display the path of ID-less components. Here's where we display the ID if it's available.
dash-renderer/src/exceptions.js
Lines 44 to 47 in 84c484b
The text was updated successfully, but these errors were encountered: