Rearrange and rename main page containers

[huong-li-nguyen]

Description

• Split up _make_page_layout into 2 sub-functions for simplified layout overwrite:
  • _get_page_divs: Creates all the relevant containers that we might want to re-arrange
  • _arrange_page_divs: Arranges all 8 containers
• Change TypedDict classes that store html.Divs to alternative syntax such that we can use dashes inside the keys instead of underscores (required for CSS IDs)
• Refactor hideable container behaviour into check _is_hidden
• Remove className and use id only for unique containers, includes renaming:
  • nav_panel_outer -> nav-panel
  • nav_bar_outer -> nav-bar
  • component_container -> components
  • control_panel_outer -> control-panel
• Remove underscores from CSS IDs and replace with dashes for main containers only as usage of dashes are better practice for CSS names (a separate PR will be created to apply the same for the rest of the code basis)

Screenshot

This graphic helps understand the current layout arrangements - please take a look:

In general, there are theoretically 8 main containers that we can re-arrange across the page:

• dashboard-title
• page-title
• settings (currently only includes theme switch)
• nav-panel
• nav-bar
• control-panel
• components
• (logo) (not available yet)

These 8 containers are allocated to these outer containers currently and these outer containers make up our page layout:

Left Side

• left-header
• left-sidebar
• left-main

Right Side

• right-header
• right-main

Notice

• I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":

  • I submit this contribution under the Apache 2.0 license and represent that I am entitled to do so on behalf of myself, my employer, or relevant third parties, as applicable.
  • I certify that (a) this contribution is my original creation and / or (b) to the extent it is not my original creation, I am authorized to submit this contribution on behalf of the original creator(s) or their licensees.
  • I certify that the use of this contribution as authorized by the Apache 2.0 license does not violate the intellectual property rights of anyone else.
  • I have not referenced individuals, products or companies in any commits, directly or indirectly
  • I have not added data or restricted code in any commits, directly or indirectly

[nadijagraca]

Looks good. Thanks for incorporating all the changes.
I have one small comment, but otherwise looks good. 🚀

[antonymilne]

Really great work and an excellent description! ⭐ 🌟 ⭐

Just some small questions and suggestions, nothing big though. Altogether this is massively better than the container arrangement when I first pulled over the code from VizX and there were lots of mysteriously nested things 💯

I'm very much enjoying the clean commit history. If you want to take it to the next level then you could pull updates from main using rebase rather than merge if you're the only person working on a branch (also possible from Github UI if you press the little arrow next to the Update button).

[antonymilne]

Somewhat related to this PR so let me ask it here... Is there a reason we have this in Dashboard.build?

dbc.Container(
        id="dashboard_container_outer",

It's the only example of the dbc.Container we have - everything else is done with html.Div. Is it for the fluid=True or just historical accident?

[huong-li-nguyen]

also possible from Github UI if you press the little arrow next to the Update button

Very good question! I think historical accident 😅

The two behave pretty much the same. The fluid=True in theory adds 15px padding to the view, but this actually never worked as we globally overwrite it with our CSS. So there is no advantage in using the dbc.Container compared to a simple html.Div as far as I know. I've replaced it everywhere now.

Read the answer on this one for reference: https://stackoverflow.com/questions/68823379/dash-dbc-container-fluid-true-does-not-cover-all-available-space

[antonymilne]

Very good question! I think historical accident 😅

The two behave pretty much the same. The fluid=True in theory adds 15px padding to the view, but this actually never worked as we globally overwrite it with our CSS. So there is no advantage in using the dbc.Container compared to a simple html.Div as far as I know. I've replaced it everywhere now.

Read the answer on this one for reference: https://stackoverflow.com/questions/68823379/dash-dbc-container-fluid-true-does-not-cover-all-available-space

Thanks for checking this. It's always bugged me that we had this inconsistency 😀 Everything looks so much cleaner than it used to now 💯

Some time next time I think we should discuss again the different options for how to handle the layout, e.g. the grid-template-area vs. using dbc.Grid vs. our current approach. @AnnMarieW had some good points here about performance on small screens here so would be good to talk it through with her I think. Also Ottis knows lots about this sort of thing so would be worth brainstorming with.

But for now I love the approach! ⭐

[huong-li-nguyen]

Very good question! I think historical accident 😅
The two behave pretty much the same. The fluid=True in theory adds 15px padding to the view, but this actually never worked as we globally overwrite it with our CSS. So there is no advantage in using the dbc.Container compared to a simple html.Div as far as I know. I've replaced it everywhere now.
Read the answer on this one for reference: https://stackoverflow.com/questions/68823379/dash-dbc-container-fluid-true-does-not-cover-all-available-space

Thanks for checking this. It's always bugged me that we had this inconsistency 😀 Everything looks so much cleaner than it used to now 💯

Some time next time I think we should discuss again the different options for how to handle the layout, e.g. the grid-template-area vs. using dbc.Grid vs. our current approach. @AnnMarieW had some good points here about performance on small screens here so would be good to talk it through with her I think. Also Ottis knows lots about this sort of thing so would be worth brainstorming with.

But for now I love the approach! ⭐

Yes, I agree! I have these topics on top of my list and to also discuss w/ @AnnMarieW ! 🚀

[AnnMarieW]

It's the only example of the dbc.Container we have - everything else is done with html.Div. Is it for the fluid=True or just historical accident?

I think the bigger question is: Why are you using Dash Bootstrap Components at all? You aren't loading a stylesheet, correct? This is a big problem since it's not uncommon to have a Bootstrap stylesheet in a user's assets folder. Here's what the example app app looks like if someone has the Spacelab theme in /assets

[huong-li-nguyen]

It's the only example of the dbc.Container we have - everything else is done with html.Div. Is it for the fluid=True or just historical accident?

I think the bigger question is: Why are you using Dash Bootstrap Components at all? You aren't loading a stylesheet, correct? This is a big problem since it's not uncommon to have a Bootstrap stylesheet in a user's assets folder. Here's what the example app app looks like if someone has the Spacelab theme in /assets

Hey @AnnMarieW, that's a very good point!

We have yet to figure out how to make templating as easy as possible. So far, we create our templates here and users can configure them in dashboard.theme. Currently, it only supports vizro_dark and vizro_light, but the future idea is to add more templates and facilitate the process for users to create their own.

We generally prefer dbc components over dcc components when dcc becomes challenging to style (some dash properties were tricky to overwrite) or when the dbc components enable additional functionality. Let me create another issue on this one so we can discuss it. :)