[docs][base] List slots in API documentation

[hbjORbj]

• I have followed (at least) the PR section of the contributing guide.

Closes #35791

Changes:

1. For every Base component, this PR creates ${ComponentName}Slots interface for slots prop (inside the interface, it has the JSDoc default value and description for each slot).
2. Parses the JSDoc for ${ComponentName}Slots interfaces and updates API JSON files
3. Create a UI for "Slots" section in API Doc, which displays name, type, default and description of each slot
4. For every Base component, this PR sets default value for slots prop and add JSDoc default value for slots (hence slots in "Props" section of the API doc now has a default value); UPDATE: Reverted this after realising that setting default values to slots prop brings implementation changes

Preview: https://deploy-preview-36104--material-ui.netlify.app/base/api/select-unstyled/#slots <- SelectUnstyled API Doc

[mui-bot]

Netlify deploy preview

https://deploy-preview-36104--material-ui.netlify.app/

Bundle size report

Details of bundle changes

Generated by 🚫 dangerJS against eb04331

[michaldudak]

Great job overall! It should be much clearer to the developers what they can use now. However, we definitely need to work on making JSDocs more comprehensive.

Was creating a separate interface for slots necessary? I don't think it'll ever be used on its own. We already have a ton of types starting with {ComponentName}Unstyled, so if we can avoid adding new ones, that would be great. I understand that it allowed you to reuse lots of code responsible for parsing the classes interface. Perhaps it wouldn't be that difficult to get to the description of {ComponentName}UnstyledProps.slots directly instead. Let me know what you think.

Also, tagging the @mui/docs-infra team for a review.

[hbjORbj]

Perhaps it wouldn't be that difficult to get to the description of {ComponentName}UnstyledProps.slots directly instead.

Are you suggesting that we add default value for slots prop like { root: 'span', badge: 'span' } and use this to parse default values of each slot?

[siriwatknp]

Instead of Type column, should it be class name instead? I think it is more useful because Type will always be ElementType for all slots. cc @michaldudak

[michaldudak]

Are you suggesting that we add default value for slots prop like { root: 'span', badge: 'span' } and use this to parse default values of each slot?

Only in JSDoc, though (unless it will cause linting errors saying that the prop must be also initialized in code).

Instead of Type column, should it be class name instead? I think it is more useful because Type will always be ElementType for all slots.

Great idea! We don't have slot class names documented anywhere, so it'll come in handy for sure.

[hbjORbj]

Only in JSDoc, though (unless it will cause linting errors saying that the prop must be also initialized in code).

Yes, the code and the default value declared in JSDoc must match to avoid the errors and to pass all CI tests.

[hbjORbj]

I added to the documentations the slot class names as @siriwatknp suggested.

[michaldudak]

Looks good! I'll do a more thorough review a bit later.
What do you think about changing the "Global class" title to "Default class"? Soon, these classes will have the possibility of being removed (#35963), so IMO it makes sense to underline they are applied by default.

[hbjORbj]

What do you think about changing the "Global class" title to "Default class"? Soon, these classes will have the possibility of being removed (#35963), so IMO it makes sense to underline they are applied by default.

Yes, it sounds better. On my way.

[siriwatknp]

👍 Awesome

[michaldudak]

Now that I look at it, the "Default" column feels a bit unclear next to "Default classes":

Perhaps changing "Default" to "Default value" could make it easier to undersdtand.

[hbjORbj]

Agree. I renamed it.

[michaldudak]

I like it!