-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[docs] Add Toolpad Core template #44415
base: master
Are you sure you want to change the base?
[docs] Add Toolpad Core template #44415
Conversation
Netlify deploy previewhttps://deploy-preview-44415--material-ui.netlify.app/ Bundle size report |
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. |
href: '/material-ui/getting-started/templates/dashboard/', | ||
source: `${sourcePrefix}/docs/data/material/getting-started/templates/dashboard`, | ||
hasDarkMode: true, | ||
}, | ||
{ | ||
title: translatation('marketingPageTitle'), | ||
description: translatation('marketingPageDescr'), | ||
title: translation('dashboardToolpadTitle'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interleaving different types of content feels like a big no-no.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
externalInput
URL when the above is merged and the Toolpad docs website is deployedPreview: https://deploy-preview-44415--material-ui.netlify.app/material-ui/getting-started/templates/