📣 Introducing Dash Labs (Dash 2.0 preview)

This is great new; totally love the callback improvements and the pulgin example for DataTable.
I am behind a firewall and pip install particular has issues for me.

Can you please confirm a conda installation for the dash-labs will be available now?

Hi @hhoeflin , I’m curious about this suggestion. Can you please elaborate?
The way I understand it, Dash components are nested within the sidebar- and other - templates because all components go inside the layout. Are you suggesting to do it the other way around, nesting template inside the components? How would that work?

Hi @hhoeflin

You are correct - the template can be considered a component that is made up of other nested components. The components in the template can be accessed in any other callbacks using their ID. If you use the auto generated id, there is an example of how to find that id in the last example in the docs here

Also, the templates can be used as part of a larger app. You can place it anywhere in a larger app layout just by adding the tpl to the layout - just like any other component that you have assigned to a variable name.


@AnnMarieW has already answered … thanks for these pointers.

I guess one question there is the need to have the “app” component around when using such a template or “component” with a callback. Would it not be better to not require the “app” at all, just register the callback in the template and only register the callback when the template is assigned to the layout?

I also like the idea of a Dash equivalent to Flask blueprints. I might be biased though, as the DashProxy object of dash-extensions is pretty close to this kind of abstaction. If such plugin structure was available, a large part of dash-extensions would be “plug and play” :slight_smile:

I haven’t had time to take the dash labs template systems for a real spin, but in my case as a more advanced user, I don’t see exactly where I would use it. Yes, the syntax is a little more compact (a bit Shiny like?), but as I understand, there is no new functionality. And since I am already comfortable with the “old” syntax, I am not likely to change unless there is a significant benefit. I guess the appeal would be mainly to new users?


I agree with you @Emil. I think the appeal for the new template system would mainly be for the new users of Dash. I think it’s just a little bit harder (less intuitive) to learn than dbc.Row and dbc.Col, but once they understand the templates, they could focus their attention on the callbacks instead of trying to build out the layout for every new app.

What I would like to better understand is how to transition from the template layout system to more control over the layout, if I wished that, especially if I wanted to control the location of the input components.

Another piece of feedback from Gary Gonzenbach:
“The coordination of bootstrap themes and templates looks like a huge hit for quickly customizing apps for clients. In Dash 2.0 would there be the possibility of having the same Output component for multiple callbacks?”

I have to make a small addendum to my previous comment. We are currently working on tool alignment across the teams in our department, and the immediate impression from our data scientists is that the Dash 2.0 features listed in this thread would be deal breakers for them. Coming from Shiny, they find the “standard” Dash syntax too verbose, and the Dash 2.0 syntax is thus a very welcome addition :slight_smile:


When you say “deal breakers” do you mean “if we include them they would hate it” or “if we include them they would love it” ?

1 Like

What I would like to better understand is how to transition from the template layout system to more control over the layout, if I wished that, especially if I wanted to control the location of the input components.

Right now the answer would be to either switch to a different template that more closely matches your needs, or use the add_component mechanism, or “fall back” to the current state of things: either html.Div-based layouts or dbc.Whatever-based layouts.

This is very similar to the Express/Graph Objects relationship in the plotly module: if you want to make a figure that Plotly Express doesn’t have a built-in function for, you can either get partway with a px function and then call .add_trace/.update_traces, or you can rebuild the figure from graph_objects. For example if you want to make a bar-and-line “combo” chart you can either use px.line and add a bar trace (or vice versa) or start from a blank go.Figure and add both traces (and redo all the other stuff that PX does for you like label axes, set up hovertemplates etc).

One thing I’d like to hear from users about is actually around what additional “mutator” type functions like add_component folks would like to see on templates to be more comfortable with using them? Plotly Figures now have a fairly rich system of add_* and update_* methods, and I can imagine Dash 2 templates having more than just add_component but right now that’s all we have spec’ed out :slight_smile:

Ah, sorry for the unclear formulation. They love it :wink:

1 Like

Hi @nicolaskruchten
Thanks for the question. One thing I would suggest is maybe a tpl.add_properties() mutator to the component constructors.
I love the component constructors because they’re easy to use, simple, and it’s very quick to build an app with them.
But a user might want more functionality out of the component at some point.

Take the built-in
tpl.dropdown_input([“A”, “B”, “C”]). Say I want to add the searchable, the persistence, or the disabled property, instead of reverting back to the original dcc.dropdown(), it would be great if I could access these properties through something like:
tpl.dropdown_input(["A", "B", "C"]).add_properties(searchable=True, disabled=False)

I think it might be useful to have something like template.to_layout() method which would print a string representation of the template that I could just copy-paste and use it as app.layout. It would be then easy to do whatever modification to the layout.

1 Like

Your tpl.dropdown_input(["A", "B", "C"]).add_properties(searchable=True, disabled=False) is already possible as tpl.dropdown_input(["A", "B", "C"], opts=dict(searchable=True, disabled=False)) actually :slight_smile:

But keep in mind that what actual underlying component “dropdown” means is template-dependent! With the DBC templates it’s a dbc.Select and with others it might be dcc.Dropdown.

1 Like

I think it might be useful to have something like template.to_layout() method which would print a string representation of the template

This is probably doable, and in fact might be a quite-generic component-traversal thing… when we do app.layout = tpl.layout(app) all we’re doing is generating a tree of components with props. A little recursive function that takes such a tree and prints out the Python code that would generate should be straightforward. Where it gets tricky is with the auto-generated IDs and the modifications that will need to be made to the callback code to wire it up to the non-template-generated layout though.


Hi All,

I published a small API update to the template system today. Please check it out in the Dash Labs 0.2.0 thread. And let’s move further discussion of the template system to that thread.

Thanks again for the feedback!

1 Like

Hey @jmmease

Thanks for the update!
I am using Dash since some weeks and just tried the 2.0 preview. I am currently building a tool and thinking about if it is already worth to change to version 2.0. The new layout system seems pretty cool!
I know it is difficult to say but is there a roadmap on when version 2.0 will be released and what features are currently missing?
Maybe I can contribute to some features.


  • Nico

Hi @NicoN97, the best estimate we have at this point is somewhere in the August to September range.

It would be great if you could play with the template system and weigh in with your impressions over in Dash Labs 0.2.0.


1 Like

First, let me take this opportunity to thank you guys for creating Dash.

As for the feedback for Dash Labs features, the flexiblecallback is handy, but the template stuff is less relevant for our use case.

The top feature we would like to see in the new Dash version is to allow multiple callbacks update the same output. We are currently using the dash-extension package to workaround this limitation, but a native support will be preferred.

1 Like

As of 10 days ago, Dash 2.0 is now available: Dash 2.0 Prerelease Candidate Available!

1 Like