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] Final polish on Base docs - formatting and style consistency #33156
Conversation
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.
Looks amazing to me-scanned it through a couple of times and nothing stood out.
Awesome work 🙌
Thanks @danilo-leal! Maybe @mnajdova and/or @michaldudak could give this one last review to make sure it's all good before merging? It's a big one so I want to make sure we have many sets of eyes on it. |
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 could just find two issues around missing slots in the slots section. The rest look splendid :)
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.
Great work, @samuelsycamore, I really like it! I do have just two comments.
Hooks _do not_ support [slot props](#slot-props), but they do support [customization props](#customization). | ||
|
||
:::info | ||
Hooks give you the most room for customization, but require more work to implement. |
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 recently realized another use case for hooks - if you're building a component library that can be customized further by developers (e.g. using the componentsProps
prop), use hooks. Unstyled components are better suited to build "closed" libraries (that's why we use hooks to build Joy components, for example).
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 think this is worth mentioning on all pages? Or maybe it would be better suited for the Usage page?
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 suppose having it just on the Usage page should be enough.
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.
Sounds good. I'll add it to #33272
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.
👍
Just applied the suggestions from @mnajdova's last review. I think this is ready to go finally! 🤞 |
I think it's time to merge this beast! There will always be more room for improvement, but I think we've established a very strong template here that I'd like to start applying across all product documentation. |
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.
A great step forward 👍
Hooks give you the most room for customization, but require more work to implement. | ||
With hooks, you can take full control over how your component is rendered, and define all the custom props and CSS classes you need. | ||
|
||
You may not need to use hooks unless you find that you're limited by the customization options of their component counterparts—for instance, if your component requires significantly different [structure](#component-slots). |
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.
Would this be better?
You may not need to use hooks unless you find that you're limited by the customization options of their component counterparts—for instance, if your component requires significantly different [structure](#component-slots). | |
You may not need to use hooks unless you find that you're limited by the customization options of their component counterparts—for instance, if your component requires a significantly different [structure](#component-slots). |
|
||
```js | ||
`ButtonUnstyled` replaces the native HTML `<button>` element. |
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.
It could be interesting to explain why (The value proposition for a developer to replace a native button) Or maybe it's better to say "extends" it.
|
||
`ClickAwayListener` is a utility component that listens for click events outside of its child. | ||
## Introduction |
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.
Is the plan to add this ## Introduction
in the rest of the docs? It seems that in Material UI we have systematically skipped it (the introduction content was left to be described under the h1), it's not consistent.
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.
Yes, I think we should apply this format across the Material UI docs as well.
|
||
{{"demo": "AccessibleBadges.js", "defaultCodeOpen": false}} | ||
{{"demo": "AccessibleBadges.js"}} |
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 think that we could keep the preview disabled. It doesn't explain how the feature works, so I feel noise for developers
{{"demo": "AccessibleBadges.js"}} | |
{{"demo": "AccessibleBadges.js", "defaultCodeOpen": false}} |
## Component size | ||
|
||
- 📦 [2.0 kB gzipped](https://bundlephobia.com/package/@mui/base@latest) |
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.
In the future, we could use Bundlephobia, https://bundlephobia.com/api/exports-sizes?package=@mui/base@5.0.0-alpha.90 and show the value associated with what we export,
``` | ||
|
||
{{"component": "modules/components/ComponentLinkHeader.js", "design": false}} | ||
### Basics |
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.
When landing on https://deploy-preview-33156--material-ui.netlify.app/base/react-badge you need to scroll a lot before you can find an actual demo of the component or one that you can copy and paste into your project. It contrasts with what we had before https://mui.com/base/react-badge/ or https://www.radix-ui.com/docs/primitives/components/tooltip. So I conclude that we miss an introduction demo, maybe under ### Basics
?
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.
This is reinforced by this feedback https://mui-org.slack.com/archives/C0170JAM7ML/p1659457895980239?thread_ts=1658732401.469249&cid=C0170JAM7ML
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.
That is a good point. We could definitely use a basic intro demo here, and probably for some other Base components as well.
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 will raise this discussion at the next team meeting, seeing
- https://reshaped.so/content/docs/components/switch
- https://headlessui.com/react/switch
- https://www.radix-ui.com/docs/primitives/components/switch
it feels nice to see a full demo first before everything else. It can even then turn into an SEO hack https://www.notion.so/mui-org/Page-image-generator-75bc177fefe64c0b899a42a6f919a907.
Regarding #33156 (comment), Radix seems to do it: cc @michaldudak, I think it's great to communicate to the developers that bundle size is a key constraint in how components are designed. |
…ui#33156) Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
https://deploy-preview-33156--material-ui.netlify.app/base/react-badge/
This is the final (?) follow up to #32072 to polish the existing Base documentation and implement consistent formatting and style.
This PR covers all component pages in the Base docs, as well as one tiny tweak to the Overview page to fix the title. Changes include:
<p>
descriptions for SEOtitle
for SEOThe primary purpose of this final round of polishing is to establish a universal template for component pages that we could use when writing and revising pages going forward. It looks like this:
Once we're satisfied with this template, we can move on to apply it to all component pages across MUI's products. I believe this will significantly improve the overall experience of our docs.
This final pass turned out to be a much bigger undertaking than I anticipated so I'm sure there are tiny details I've missed! The big-picture formatting is what I'm most concerned with here.