Potential ways forward regarding a smoother experience in Jupyter

[mckinsey]

Potential ways forward regarding a smoother experience in Jupyter

[antonymilne]

I'll need to spend some time properly thinking this all through, since it's a tricky topic and not something we should rush. But just to note another possible idea while I remember: maybe we need another method on VizroBaseModel which enables you to instantiate and register a model in one go. This would avoid you needing to remember to manually call register after you've created a model in pre-build, but I'm not sure exactly what that register method would do.

[antonymilne]

Another possible solution might be to clear the managers on shutdown of the flask process. I did this in an old solution where we used to copy assets to a temporary directory. It's not super reliable (e.g. from memory there's some complexities with multiple threads), but maybe in the context of Jupyter where you're unlikely to be doing that it would work well.

[antonymilne]

Another idea: a global dashboard object and navigating through that hierarchy (as in the medium term solution above) might actually be a good long term solution. This would probably avoid difficulties with needing to recursively register. But then how would pre_build know what to operate on?

Or it could be Vizro.dashboard - think about comments about Dash use in #109.

[antonymilne]

Another point against hierarchical registration or at least in favour of keeping _items_with_type: when we implement components nested in tabs or containers, it gets harder to collect e.g. all components on the page.

Note that #142 got rid of several calls to _items_with_type that required the dashboard.

[antonymilne]

Closing this just so we don't have the comments spread over too many different places. #120 is a good fix for Jupyter for now, and the real issue here is much deeper than just Jupyter - will continue the conversation in #109 and #111 anyway.