You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our React v9 stories currently include a lot of boilerplate and configuration in addition to the base functionality provided by the component. This makes it difficult for consumers to understand what React v9 components are providing and what they can do with them.
Consumers visually scan our docs, look at often customized implementations of our components, and get the wrong impression. They sometimes think we offer overly specialized components for Office cases only. It is not clear what part of our stories are provided by v9 itself vs which parts are provided by the customized story implementation details.
Example, Card specifically was reported to me as "not fitting our use cases at all" by more than one partner. This is because the Card examples appear to be very specific Office cards. However, the v9 card is simply a container component with minimal styles. It also includes a couple layout slots and a horizontal/vertical variation. It fits a vast number of card cases, but our current docs do not show the base Card capabilities. We only show Office implementations of the cards.
Proposal
The proposal to fix this issue is to provide two "types" of stories:
Definition (missing)
Usage (current)
Definition Stories
Goal: Teach the user what the component does as quick as possible
How:
Do not use style overrides
Do not use factories for creating stories, inline all code for immediate clarity
Include the bare minimum props and content to show each feature
Separately, we should consider highlighting the anatomy in use in the story, see #28326 for a prototype, namely it should:
Should show all components/slots used in the story
Should show components/slots used in the public API only (not components used internally)
Should follow Portals (fibers)
This PR
A visual prototype of the a mostly complete Card definition story is provided for demonstration only. The story file should be ignored as it would be split into multiple files. The definition stories would also be organized under some area apart from the usage stories. However, the prototype is sufficient for visually showing how a set of "definition stories" would step through the API for a given component.
Closing this out as part of a review-queue cleanup: there has been no activity here for roughly 1104 days, and the branch no longer merges cleanly against master.
This is not a rejection on merit — it's just housekeeping so the review queue reflects work that's actually in flight. If you're still planning to pick this up, please reopen it or open a fresh PR against master and we'll get it reviewed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current Issue
Our React v9 stories currently include a lot of boilerplate and configuration in addition to the base functionality provided by the component. This makes it difficult for consumers to understand what React v9 components are providing and what they can do with them.
Consumers visually scan our docs, look at often customized implementations of our components, and get the wrong impression. They sometimes think we offer overly specialized components for Office cases only. It is not clear what part of our stories are provided by v9 itself vs which parts are provided by the customized story implementation details.
Example, Card specifically was reported to me as "not fitting our use cases at all" by more than one partner. This is because the Card examples appear to be very specific Office cards. However, the v9 card is simply a container component with minimal styles. It also includes a couple layout slots and a horizontal/vertical variation. It fits a vast number of card cases, but our current docs do not show the base Card capabilities. We only show Office implementations of the cards.
Proposal
The proposal to fix this issue is to provide two "types" of stories:
Definition Stories
Goal: Teach the user what the component does as quick as possible
How:
Separately, we should consider highlighting the anatomy in use in the story, see #28326 for a prototype, namely it should:
This PR
A visual prototype of the a mostly complete Card definition story is provided for demonstration only. The story file should be ignored as it would be split into multiple files. The definition stories would also be organized under some area apart from the usage stories. However, the prototype is sufficient for visually showing how a set of "definition stories" would step through the API for a given component.
How to test: http://localhost:3000/?path=/docs/components-card-card--definition#definition
Related Issue(s)
Visual Reference
Key aspects: