Port over draft components

[camertron]

See https://github.com/primer/design/pull/710 for the migration of deprecated components.

This PR migrates docs for draft React components from the old primer.style/react site to the new docsite. This was not a straightforward migration, but was significantly easier than deprecated components, since all draft components are available in components.json.

However, draft components presented the following challenges:

1. Additional documentation is present in bespoke .md files.
2. Although all draft components are listed in components.json, they are often listed with inconsistent IDs. For example, dialog's ID is drafts_dialog, but select panel's is selectpanel_v2. Note that the alpha version of select panel has an ID of select_panel 🤷
3. Some components listed under "Drafts" on primer.style/react (the old docsite) are actually deprecated in components.json.

The following draft components have been migrated in this PR:

• DataTable: This one was actually already available in the new docsite.
• Dialog v2: Available at /components/dialog/react/draft
• Hidden: Added a new overview page and the draft component page.
• InlineAutocomplete: Deprecated.
• MarkdownEditor: Deprecated.
• MarkdownViewer: Deprecated
• PageHeader: Dedicated page available at /components/page-header/react/draft
• SelectPanel: Dedicated page available at /components/selectpanel/react/draft
• Tooltip: Dedicated page available at /components/tooltip/react/draft

NOTE: I discovered you can export a special Layout component from .mdx files, which greatly simplified several of the already-migrated deprecated components.

[mperrotti]

Additional documentation is present in bespoke .md files.

I think we're trying to to move away from this and rely mostly on Storybook and .docs.json files. cc @broccolini @joshblack @pksjce @siddharthkp

---

Although all draft components are listed in components.json, they are often listed with inconsistent IDs Some components listed under "Drafts" on primer.style/react (the old docsite) are actually deprecated in components.json

Oof - this is no good. We should correct these inconsistencies. @camertron - are you opening a PR to handle this in primer/react? Or should I?

[mperrotti]

After giving it more thought, I think we need to have a different react ID for the "draft" version of an existing component. They're often a full rebuild of the original, and have different component APIs.

[camertron]

After giving it more thought, I think we need to have a different react ID for the "draft" version of an existing component. They're often a full rebuild of the original, and have different component APIs.

This is an interesting point. As things stand now, components can only have one status, which includes draft, deprecated, etc. The thing is, we could have three versions of the same component, two of which are deprecated, but there's no way of expressing that in the current system. I think we should have two fields, one for the component's version and one for its status.

[camertron]

I think we're trying to to move away from this and rely mostly on Storybook and .docs.json files.

For sure. Most of those bespoke .md files actually import the associated .docs.json file and use it to render component props. However they also contain documentation that is separate from what's contained in components.json (the amalgamation of all the .docs.json files, built by CI), and I think in some cases it's important to express those longer-form docs. We could add them to components.json, but JSON is a pretty bad medium for long-form text, especially markdown.

Many of your review feedback here is specific to the contents of these bespoke .md files. For the most part, I copied these over wholesale from primer/react. My goal is simply to make them look decent so we can unpublish and archive the old docsite. Since we're focusing on a revamped docs experience this quarter, I don't think it makes sense to put too much more time and effort into getting them 100% correct, especially considering they're drafts anyway.

[mperrotti]

Many of your review feedback here is specific to the contents of these bespoke .md files.

Feel free to ignore that feedback so we don't blow up the scope of this PR too much. We can take care of it in a follow-up.

[mperrotti]

In your first Rewatch video that explains our documentation infrastructure (around the 10-minute mark), you say that we shouldn't be adding content in a {component-name}/react/{status}.mdx file anymore. Then in your second Rewatch video (around the 12-minute mark) you mention wanting to clean up these bespoke pages next quarter. Have we started strategizing on how we'll do this work?