Feature : Components Documentation for "rest props"

[Vrishabhsk]

What?

• Extend the documentation for component which incorporate and allow rest props

Why?

• Components: Document when "rest props" are passed down to underlying element/component #67979

Screenshots or screencast

Before	After

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Vrishabhsk <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: ciampo <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[mirka]

Displaying it as a fake arg is kind of interesting!

We have some subtle concerns we need to balance here though, which are:

• We can't do this in the props tables for subcomponents. Not a blocker, but something to think about.
• As you can see in this file too, we're gradually migrating the component READMEs to auto-generated versions. So ideally we want one canonical source of this information, which we automatically display in multiple locations (e.g. README, Storybook).

So I'm thinking maybe we can put this information in a designated field in the docs-manifest.json, from which we can display it as a fake prop in Storybook and as a line in the auto-generated README. What do you think?