Repository navigation
refactor(ui): bring Mosaic Button and Input under the complexity limit - #9751
alexcarpenter wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 24cfbed The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueComment |
|
Closing. The reductions here are mostly metric-chasing: cyclomatic complexity counts every |
Description
Stacked on #9749. A worked example of clearing two grandfathered
complexitysuppressions, to show what a reduction looks like before deciding how far to push the rule.Button (25 → 14). The stylex composition moves into a
buttonStylePropsfunction alongside the two derived flags it alone uses.MosaicButtonkeeps resolving props againstButtonContextand rendering. No behaviour change.Input (28 → 15).
useOptionalFieldControlPropsalready returns every control attribute with the own prop as fallback, ornulloutside aField. The fivefieldProps?.x ?? xlookups collapse to onefieldProps ?? ownPropschoice, and the two variant style conditionals become a lookup. No behaviour change.Both stale entries are pruned from
packages/ui/eslint-suppressions.json, so this is also the first run of the prune flow described in #9749.Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change