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ā 
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
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ā ?
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
Ah, sorry for the unclear formulation. They love it 
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.
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
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.
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!
-Jon
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.
Thanks!
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.
Thanks!
-Jon
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.