Skip to content

Prototype props table for design system documentation #103561

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

Open
wants to merge 6 commits into
base: trunk
Choose a base branch
from

Conversation

aduth
Copy link
Member

@aduth aduth commented May 20, 2025

Closes DS-206

Proposed Changes

  • Adds script as part of @automattic/components package build to compile documentation metadata for documented components
  • Updates design system documentation to use said metadata to display a table of props

This is meant to be an early, prototype implementation, subject to design refinement.

For review, consider:

  • Is this workflow sensible and scalable?
  • Can it support how we intend to use these props in a published site deployment process?
  • Are the assumptions around how we can parse components accurate?

Additional notes:

  • I had attempted to reuse Storybook components directly, but they are not especially well-suited to being used outside a Storybook context. Additionally, I don't know how much of the Storybook "experience" we would want to set as an expectation within our design system site. The established tooling around props parsing should be straight-forward enough to provide us the information we need.
  • This uses a similar approach to component documentation generation in WordPress

Why are these changes being made?

  • To be used as part of the technical reference for a design system component

Testing Instructions

Packages need to be built first:

yarn build-packages

Then, start the documentation site:

yarn workspace @automattic/design-system-docs start

Navigate to "Components" and verify that a props table is shown for Summary Button and Breadcrumbs.

image

Pre-merge Checklist

  • Has the general commit checklist been followed? (PCYsg-hS-p2)
  • Have you written new tests for your changes?
  • Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
  • Have you checked for TypeScript, React or other console errors?
  • Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
  • Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
    • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
  • For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

@aduth aduth requested a review from a team as a code owner May 20, 2025 16:00
@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label May 20, 2025
Comment on lines +21 to +42
const pick = < O extends Record< string, any >, K extends Array< keyof O > >(
obj: O,
keys: K
): Pick< O, K[ number ] > =>
Object.fromEntries( Object.entries( obj ).filter( ( [ key ] ) => keys.includes( key ) ) ) as Pick<
O,
K[ number ]
>;

const omit = < O extends Record< string, any >, K extends Array< keyof O > >(
obj: O,
keys: K
): Omit< O, K[ number ] > =>
Object.fromEntries(
Object.entries( obj ).filter( ( [ key ] ) => ! keys.includes( key ) )
) as Omit< O, K[ number ] >;

const mapValues = < V, MV >(
obj: Record< string, V >,
fn: ( value: V ) => MV
): Record< string, MV > =>
Object.fromEntries( Object.entries( obj ).map( ( [ key, value ] ) => [ key, fn( value ) ] ) );
Copy link
Member Author

Choose a reason for hiding this comment

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

This is a good example of where rolling our own utilities is not so fun 🙃 (Re: #103048 (comment))

Comment on lines +17 to +19
const DOCUMENTED_COMPONENTS = [ 'breadcrumbs', 'summary-button' ];

const files = DOCUMENTED_COMPONENTS.map( ( component ) => `${ component }/index.tsx` );
Copy link
Member Author

Choose a reason for hiding this comment

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

I think in the future this would ideally be something we don't maintain as a list and instead glob( 'src/*/index.tsx' ). But react-docgen-typescript is pretty slow at parsing, and we have a lot of components -- most of which we don't plan on keeping here long-term. So for now I went with an allowlist.

@matticbot
Copy link
Contributor

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

},
"./styles/*": {
"calypso:src": "./styles/*"
},
"./metadata": {
"dsdocs:src": "./dist/metadata.js",
Copy link
Member Author

@aduth aduth May 20, 2025

Choose a reason for hiding this comment

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

This and the inline Docusaurus plugin are meant to kinda "hide" this from the public interface of the package. In the future, if we want to standardize and expose this, we should probably just have this available as "import"

Copy link
Member Author

Choose a reason for hiding this comment

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

I reverted this in 7f2d6ab to use plain, "public" import. Docusaurus doesn't seem to be very compatible with using conditionNames overrides in the Webpack configuration. I was getting a bunch of errors in how the internal theme's CSS modules were being processed:

Example:

Syntax error: /Code/wp-calypso/node_modules/@docusaurus/theme-classic/lib/theme/AnnouncementBar/CloseButton/styles.module.css Unknown word "closeButton_rfix" (2:31)

  1 | // extracted by mini-css-extract-plugin
> 2 | export default {"closeButton":"closeButton_rfix"};
    |                               ^

@@ -0,0 +1,53 @@
import metadata from '@automattic/components/metadata';
import { VisuallyHidden } from '@wordpress/components';
Copy link
Member Author

Choose a reason for hiding this comment

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

Problem: I'm running into some strange errors when building the site, specifically during static site generation. I'm wondering if there might be some incompatibility with using WordPress components in a statically rendered context?

I don't see Gutenberg rendering this Emotion Cache provider anywhere. I also tried to "swizzle" a wrapper to provide the context, but the error persisted.

Possible solution could be to use ScreenReaderText from @automattic/components, or create a duplicate copy in this project, or avoid the visually-hidden content altogether.

      [errors]: [
        Error: Can't render static file for pathname "/components/summary-button"
            at generateStaticFile (/Code/wp-calypso/node_modules/@docusaurus/core/lib/ssg/ssg.js:167:15)
            at processTicksAndRejections (node:internal/process/task_queues:105:5)
            at runNextTicks (node:internal/process/task_queues:69:3)
            at process.processImmediate (node:internal/timers:459:9)
            at async /Code/wp-calypso/node_modules/p-map/index.js:57:22 {
          [cause]: Error: The `useCx` hook should be only used within a valid Emotion Cache Context
              at server.bundle.js:7113:13
              at useContextSystem (server.bundle.js:7176:19)
              at UnconnectedVisuallyHidden (server.bundle.js:7608:7)
              at Uc (server.bundle.js:4062:44)
              at Xc (server.bundle.js:4067:395)
              at Z (server.bundle.js:4070:89)
              at Yc (server.bundle.js:4073:98)
              at $c (server.bundle.js:4072:140)
              at Z (server.bundle.js:4070:345)
              at Xc (server.bundle.js:4065:476)

Copy link
Member Author

Choose a reason for hiding this comment

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

I opted to replace in fcc2522 with static text. This table will need some design refinement anyways, so let's make it a future problem to solve.

@matticbot
Copy link
Contributor

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

  • design-system-docs
  • notifications
  • wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug add/ds-docs-props on your sandbox.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants