Skip to content
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

Port over draft components #718

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Port over draft components #718

wants to merge 2 commits into from

Conversation

camertron
Copy link
Contributor

@camertron camertron commented Jan 29, 2024

See #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
Copy link
Contributor

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?

Copy link
Contributor

@mperrotti mperrotti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewing this PR has given me a scary look into the current state of our component docs. I did my best to make helpful suggestions, but I don't think I fully understand how things work under the hood. Please share any documentation, Looms, etc that might help me better understand how everything works.

content/components/dialog/react/draft.mdx Show resolved Hide resolved
content/components/dialog/react/draft.mdx Show resolved Hide resolved
@@ -0,0 +1,78 @@
import React from 'react'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually extracted this from react-component-layout.tsx, meaning it's the props table we've been using on all our React component pages for a while now. That said, I'm happy to look at replacing it for consistency.


<ReactPropsTable props={props.data.reactComponent.props} />

### DialogHeaderProps
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I correct in assuming that we have to manually render these tables in Markdown because we don't have a way to document these types in the current shape of the *.docs.json objects?

A good follow-up issue could be to solve this problem so we don't have to manually render stuff like this.

Copy link
Contributor Author

@camertron camertron Jan 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, I just copy/pasted this from primer/react. The info for all these props exists in components.json, so I think we can remove this and let the layout render the props table(s) instead.

Comment on lines +128 to +152
### useConfirm hook

An alternate way to use `ConfirmationDialog` is with the `useConfirm()` hook. It takes no parameters and returns an `async` function, `confirm`. When `confirm` is called (see ConfirmOptions below for its argument), it shows the confirmation dialog. When the dialog is dismissed, a promise is resolved with `true` or `false` depending on whether or not the confirm button was used.

### Example (with `useConfirm` hook)

```javascript live noinline
function ShorthandExample2() {
const confirm = useConfirm()
const buttonClick = React.useCallback(
async function (e) {
if (await confirm({title: 'Are you sure?', content: 'You must confirm this action to continue.'})) {
e.target.textContent = 'Confirmed!'
}
},
[confirm],
)
return (
<>
<Button onClick={buttonClick}>Confirmable action</Button>
</>
)
}
render(<ShorthandExample2 />)
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this to the useConfirm() hook docs and just link there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm yeah that's a good idea.

@@ -0,0 +1,22 @@
---
title: Markdown viewer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been moved to Primer Recipes and doesn't need to ported over https://ui.githubapp.com/storybook/?path=/story/recipes-markdownviewer--default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible someone is using this component in dotcom and needs to reference the deprecated docs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not seeing it in Primer Query

</ReactComponentPage>
}

The `MarkdownViewer` displays rendered Markdown and handles interaction (link clicking and checkbox checking/unchecking) with that content.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible someone is using this component in dotcom and needs to reference the deprecated docs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not seeing it in Primer Query

@@ -215,6 +215,20 @@ async function sourcePrimerRailsData({actions, createNodeId, createContentDigest
}
}

const reactIdMap = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So do we have to manually handle the data differences between the draft component and the "old" component?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sort of. This map just helps unify all the components under one name so we can render a status dropdown.

Comment on lines +238 to +239
- title: Hidden
url: /components/hidden
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should remove internal components from the sidebar until we have a plan for how we want to handle documentation for internal components.

Suggested change
- title: Hidden
url: /components/hidden

Comment on lines +342 to +347
- title: Inline autocomplete
url: /deprecated-components/inline-autocomplete
- title: Markdown editor
url: /deprecated-components/markdown-editor
- title: Markdown viewer
url: /deprecated-components/markdown-viewer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These have been moved to Primer Recipes and don't need to be maintained in the Primer core docs.

Suggested change
- title: Inline autocomplete
url: /deprecated-components/inline-autocomplete
- title: Markdown editor
url: /deprecated-components/markdown-editor
- title: Markdown viewer
url: /deprecated-components/markdown-viewer

@mperrotti
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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.

},
}}
>
<StatusMenu currentStatus={status} statuses={statuses} parentPath={`${data.sitePage.path}/react`} />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I navigate to /latest, will I get the newest version (usually "draft"), or will I get the version that's higher precedence in the statusOrder array?

@mperrotti
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants