Dash bootstrap and Dash mantine both have the ability to feed these settings when everything is set in a grid layout. This works well in a lot of cases.
But sometimes the effort of trying to have things in a grid layout is too difficult to implement (custom dashboard layout where the users can drag the graphs anywhere) this is where css can apply.
Take my reference earlier:
@media only screen and max-width (920px) {
.dash-graph {
width: 100% !important;
height: 65% !important;
position: relative !important;
}
}
#design-area .dash-graph[style] {
flex-grow: 1 !important;
flex-shrink: 0 !important;
position: relative !important;
width: 100% !important;
height: 50vh !important;
display: flex !important;
top: 0px !important;
left: 0px !important;
}
Width 100% obviously takes up the full width of the container it is positioned in. Height, 65% of the container it is in. Position relative means that if there are multiple graphs in the same container, they will now stack regardless of position.
The design-area is a real world example of me overwriting the graph when styling is provided under a specific screen query. I provide everything that is normally present within the inline-styling for the design. (design-area is from my Dashboard-Helper where you can create custom layouts).
The thing I like about css, is the ability to apply settings with broad strokes via classnames, this isnt just about applying settings to how the element looks, but also to how the element can be displayed in the layout.
With that said, can you reuse things like @AnnMarieW mentioned, and the answer is yes.
Let’s take her app that she demonstrated with, its very easy, I made some adjustments, and then repeated the layout of the accordion and graph a second time.
import dash
import dash_bootstrap_components as dbc
from dash import dcc, html
from dash_bootstrap_templates import load_figure_template
import plotly.express as px
load_figure_template("slate")
app = dash.Dash(external_stylesheets=[dbc.themes.SLATE])
h3_ = html.H3("Select Artist(s)")
uxSz = {}
uxSz['acc'] = {'md': 9, 'lg': 6}
button = dbc.Button(
id="submit_button",
n_clicks=0,
children="Submit",
)
accordion =dbc.Accordion(
[
dbc.AccordionItem([], title="Billy Strings"),
dbc.AccordionItem([], title="Goose"),
dbc.AccordionItem([], title="Grateful Dead"),
dbc.AccordionItem([], title="Phish"),
dbc.AccordionItem([], title="Widespread Panic"),
],
)
app.layout = dbc.Container(
[
h3_,
dbc.Row(
[
dbc.Col(accordion, **uxSz['acc']),
dbc.Col(button),
],
className="my-4"
),
dcc.Graph(figure=px.scatter()),
dbc.Row(
[
dbc.Col(accordion, **uxSz['acc']),
dbc.Col(button),
],
className="my-4"
),
dcc.Graph(figure=px.scatter()),
]
)
if __name__ == "__main__":
app.run_server(debug=True)
Now, we could type in md=9, lg=6 across each time that we wanted to specify the layout, but once this gets spread out among multiple elements and layouts, if you found an issue and wanted to update, you’d have to go through each instance and update it. This is where the dictionary comes into play, you can save your settings as key: value pairs, then wherever you want this specific design, you can call it by using ** in front of the specific dictionary you want to reference, in this case it was uxSz['acc'] which when used with the ** it broke out into md=9, lg=6.
If you use pages and multiple layouts, using a dictionary from a utils directory that you import gives you the opportunity to save these settings in one location and be able to adjust them simply. Also note, they can apply to any settings across the board (className, color, etc).
