In what sense does dash_labs.plugins.page_container truly differ from dash.page_container?
Because variable_containg_blueprint.register(dash_app, "some_value", path="/") seems to work perfectly fine as it pops up in the dash.page_container property. I do have to add the PrefixIdTransform to each DashBlueprint instance, but that’s fine!
I’m wondering in which sense they actually differ and whether my approach might cause any issues in the future (haven’t found any issues yet, but who knows).
Because dash_labs contains a notice on their GitHub page not to use it in production, I try to avoid it, which is why I want to be sure that my approach is a valid approach or not.
Hi @coderik
The Pages feature (including the dash.page_container) was originally developed in dash-labs. Any projects in Dash Labs should not be used in production because they are prototypes and will likely have breaking changes.
Once Pages was included with Dash, it was no longer developed in dash-labs – so that version is very old.
Why are you using the dash-labs version? Is there some feature there that’s not in the Dash version?
Thank you for your quick response @AnnMarieW
Well, I stumbled upon dash_labs because we use the DashProxy (from dash-extensions) in our projects, because that should be able to fire callbacks without necessary output and to target an output by multiple callbacks. But I’m not sure if the current version of Dash even make those extras obsolete? Anyways, they still use dash_labs in their documentation: Dash
But now I’m even wondering if that repository is that well maintained
I am working in a new major release of dash-extensions, which will leverage the (great!) new features of Dash 2.9. There is some work to be done though, which is why it takes a bit of time to get it ready
Thank you @Emil and @AnnMarieW !! In that case I’ll stick with my current solution till the new version of dash-extensions has been released Thanks again!
