docs: add headless component authoring skill - #36502
docs: add headless component authoring skill#36502Dmytro Kirpa (dmytrokirpa) wants to merge 3 commits into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 806b7b8e-562f-4b2a-b4f5-b9d06fc6131f
📊 Bundle size report✅ No changes found |
|
Pull request demo site: URL |
| 6. Record every inventory row as implemented, intentionally excluded with a | ||
| source-backed reason, or unresolved. Trace implemented rows through: | ||
| `types/exports -> hook/context -> rendered DOM/slots -> test or story`. | ||
| 7. Plan the change as two stacked PRs before editing: |
There was a problem hiding this comment.
if we need regression test for styled hook, then it should be 3 separate PRs, do you think we should have that covered by skill too?
| - When adding a new v9 base hook, follow the repository-enforced signature: | ||
| `useComponentNameBase_unstable(props, ref?)`, with an explicitly typed | ||
| `props` parameter and `ref` typed as `React.Ref<...>`. | ||
| - Keep base hooks free of Tabster and other forbidden focus/keyboard runtimes. |
There was a problem hiding this comment.
should we mention that icons should not be part of base hooks & bundleIcon on module level?
| State attributes are the supported CSS targeting contract. | ||
|
|
||
| - Presence state: emit `''` when true and omit when false. | ||
| - Boolean-valued state: emit `'true'` or `'false'` when both values are |
There was a problem hiding this comment.
should not it also following presence / absence approach?
| 6. Add a default story plus stories for important behavioral states. | ||
| 7. Exercise the primary interaction instead of rendering only static variants. | ||
| Interactive stories should drive the real component behavior and assert the | ||
| resulting role/ARIA/data state in a `play` function. Cover the inverse action |
There was a problem hiding this comment.
AFAIR we do not use play functions, that was probably migrated from the 1JS skill, right?
There was a problem hiding this comment.
from CompoundButton PR:
| --package @fluentui/react-<name> --type minor \ | ||
| --message "feat(react-<name>): expose headless base APIs" | ||
|
|
||
| # top branch, after editing only the headless library and stories |
There was a problem hiding this comment.
we should correct a bit these examples with beachball instructions as we following zero based semver for headless until we are stable
| `yarn beachball change` form; never create or edit them manually. | ||
| - After generation, inspect the new JSON file and verify it contains exactly the | ||
| owning package and no inherited package from another stack layer. | ||
| - New public base exports and new headless primitives are normally `minor` |
There was a problem hiding this comment.
here we should also correct it, it will be correct later when headless will become stable
|
|
||
| ### Renderer and Context | ||
|
|
||
| - Re-export or alias the upstream unstable renderer when its slot structure is |
There was a problem hiding this comment.
maybe some examples needed, I see that for CompoundButton it created it in a following format, instead of one line re-export:
import { renderCompoundButton_unstable } from '@fluentui/react-button';
/**
* Renders a CompoundButton component.
*/
export const renderCompoundButton = renderCompoundButton_unstable;| # top branch, after editing only the headless library and stories | ||
| yarn beachball change --no-commit --branch master \ | ||
| --package @fluentui/react-headless-components-preview --type minor \ | ||
| --message "feat(react-headless-components-preview): add <ComponentName>" |
There was a problem hiding this comment.
| --message "feat(react-headless-components-preview): add <ComponentName>" | |
| --message "feat: add <ComponentName>" |
I think we can omit the package scope in message as change file has packageName
2 participants
Summary
gh stackworkflow separating component-package base APIs from the dependent headless packageValidation
gh stackand Beachball flags used by the workflowNo Beachball change file is required because this change does not modify a published package.