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.
alexcjohnson
commented
5 years ago
(From https://github.com/plotly/dash-core-components/pull/532)
In
dash-renderer, we now providesetPropsfor all components, regardless of whether they are connected to the backend.However, the
setPropsthat we provide needs an ID in order for it to update the component:https://github.com/plotly/dash-renderer/blob/84c484b26452458a28843d02e4431cc88a623e14/src/TreeContainer.js#L146-L181
We should provide a function
setPropsno 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
pathstore: 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:TreeContainerand use that path in our dynamicsetPropsconstruction.setPropsor 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. https://github.com/plotly/dash-renderer/blob/84c484b26452458a28843d02e4431cc88a623e14/src/exceptions.js#L44-L47