[docs] Add Toolpad Core template link

[bharatkashyap]

• Closes Link Toolpad Core template from Material UI toolpad#4409
• To merge only after [docs] Host themed template under mui.com toolpad#4415 and [docs] Add Templates listing to examples page toolpad#4449 are merged

Preview: https://deploy-preview-44415--material-ui.netlify.app/material-ui/getting-started/templates/

[mui-bot]

Netlify deploy preview

• docs/data/material/getting-started/templates/templates.md

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 56a0626

[oliviertassinari]

This relates to the discussion in https://github.com/mui/mui-private/pull/13, https://github.com/mui/mui-private/issues/648, and https://github.com/mui/mui-private/issues/569.

[oliviertassinari]

Interleaving different types of content feels like a big no-no.

[bharatkashyap]

Do you mean we should create a separate section for Toolpad Core templates on this page, or create a separate page for them, or do you mean that the Toolpad-specific copy should be stored separately from the rest of the content (not in translations.json?)

[samuelsycamore]

I would keep the Toolpad templates separate from the rest of the templates, because they seem to serve somewhat different use cases and I'm afraid we'd be presenting users with too many options. I think the way this page is currently structured with Toolpad Core as its own section makes the most sense. (I've suggested some copyedits to this section in #44461 to say more about Toolpad's value proposition.)

[oliviertassinari]

@bharatkashyap Right so not the current shape.

Now, I'm not sure what's the right way to approach this, but at first sight, I would imagine we would have nothing else? I mean, having a link to Toolpad from this page that lists all the existing Toolpad templates seems great, similar to how the premium store items can be browsed.

We covered a bit of Toolpad product architecture in today's https://www.notion.so/mui-org/product-Company-Product-Meeting-2024-11-18-135cbfe7b66080518203cff028b28579. The main thought was that:

• We want to spend 70% of our time optimizing what works, low risks. 20% of things there are more risky. 10% in bolder bets, high chance to fail but high payouts. Existing teams can do the 70% and the 20%, but the 10% is usually out of reach for them. Part of why resources are allocated to Toolpad is to allow us to go after those 10%
• https://pro.ant.design/, Refine is closer to what Toolpad is about, ready-to-use primitives/components specifically for building quickly CRUD apps, and internal tools.

How do we know if a feature is right for Toolpad or another place in the stack? In my view, it's about:

• It would make sense to have an integration with most of the other UI libraries.
• It's not about component complexity, if its, Base UI X - MUI X sounds like the right place.
• It's not about design, if it's, MUI sounds like the right place.
• It relates to building internal tools (and potentially, but didn't commit to this yet, anything that can support components with a backend API)

For example:

• Blocks, Layouts are Material UI features, so almost all design output from Toolpad should be coming from Material UI, e.g. https://tremor.so/ is not what Toolpad is about but what Material UI is about. Toolpad supports Material UI.
• Rich layouts, things that rely on Material UI design, but are operationalized them specifically for internal tools make sense in Toolpad, e.g. https://procomponents.ant.design/en-US/components/layout?tab=api. I definitely don't see this a MUI X (not advanced enough, too design focused) or Material UI feature (too internal tool focused). Now if the API is composable, and not a big moonlight, then OK, could be Material UI, same reason as why https://ui.shadcn.com/docs/components/sidebar. If those are purely about UI (visual, no logic), MUI X could be the perfect place to host them.
• Form components, e.g. https://procomponents.ant.design/en-US/components/form. This could fit great in Base UI, but could be too advanced, so potentially Base UI X.

cc @joserodolfofreitas see if this resonates.

[prakhargupta1]

I agree that putting Toolpad template in it's own section will help users distinguish between the templates. We were earlier thinking that it would be better if the user could see Toolpad template before scroll, but due to the design revamp of this page, scrolling is inevitable. So, a separate section will help visually differentiate.

We'll replace the dashboardLayout demo with the hosted Toolpad core template. 👍

[oliviertassinari]

Yeah, but this list of templates demos using the Toolpad primitives should be in Toolpad's docs, not in Material UI's docs because it's not a Material UI feature or value proposition of Material UI.

[prakhargupta1]

Listing Toolpad template here will only make it more discoverable to the Material UI users who are looking for templates. Some of them may be interested in it, so I think we should have it here, at the bottom, in a section of its own.
Also, the templates docs page attracts many users, so not listing it here, would be a missed opportunity.

[oliviertassinari]

Listing Toolpad template here will only make it more discoverable to the Material UI users who are looking for templates. Some of them may be interested in it, so I think we should have it here, at the bottom, in a section of its own.

@prakhargupta1 Referencing Toolpad here makes sense to me, a person reaching for a template has about a 25% probability to be a user we build Toolpad for (internal tool 0.5 * simple use cases 0.5). It's also at the right time in the user journey.

However,

• for the majority of the people (75%) it's noise
• for the people that use the different product it creates confusion as to what is what
• for the team maintaining Toolpad, it makes them update places outside of their scope

So It seems that the only viable option is to reference Toolapd like we do for the template market: so no list, but a link.