refactor(react): trim high-usage boundaries - #5313
Closed
somebody32 wants to merge 1 commit into
Closed
Conversation
Contributor
🔍 Review policy: Code changeDefault rule: any other change needs one approval from f0-devs (rule 4). Module ownership (via CODEOWNERS)
Declared in each module's Required approvals
How this was decided
Policy source: |
Contributor
📦 Alpha Package Version PublishedUse Use |
Contributor
🔍 Visual review for your branch is published 🔍Here are the links to: |
Contributor
♿ Accessibility (axe) — components changed in this PR30 issues across 29 stories — all non-blocking (
Scope: only stories in the files/component folders this PR changed. It can't yet flag downstream ripple from shared-code/token changes, or diff against |
Contributor
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This draft stacks on #5312 and uses an exact Factorial production-usage audit to trim the highest-value reusable runtime boundaries while preserving public APIs and behavior. It also makes the preserved ESM graph self-contained for Atlaskit consumers and keeps the existing legacy experimental import path tree-shakeable for Factorial without a migration prerequisite.
Implementation details
Production usage evidence
The audit used Factorial origin/main at 81a7538e2eb432f2fbf6c27629917109ad9da6d8. It scanned all 4,559 source files mentioning F0 and counted 4,008 production files after excluding tests, stories, generated files, fixtures, and type-only imports.
Highest direct production usage included F0Box at 6,459 references in 969 files, F0Text at 1,511 in 588, F0Dialog at 994 in 470, f0FormField at 937 in 211, and F0Button at 885 in 526. Factorial also has 1,438 production imports from the legacy dist/experimental path.
F0Form was deliberately not made the center of this PR: it has only 27 references in 26 production files despite its large packed boundary.
Packed before and after evidence
Measured Brotli initial JavaScript from the packed package:
Cloudflare-style esbuild probes now hold F0Button at 392.4 KiB raw, root F0Button at 401.9 KiB, legacy Stack at 165.9 KiB, legacy F0TableOfContent at 2,693.7 KiB, and F0Dialog plus F0Button at 3,653.6 KiB.
An attempted eager SVG URL replacement for the flag registry produced much smaller but invalid post-esbuild URLs. It was rejected and removed before this commit. The reported numbers preserve the correct inline flag components and are the honest release values.
Validation
Remaining boundaries
The generic AvatarVariant contract still makes F0Card, F0Dialog, and F0Select retain the complete flag registry when any runtime avatar variant is accepted. Removing that cost safely requires an API or asset-delivery redesign; this PR does not hide it behind relocation-unsafe URLs.
F0Form remains about 1.33 MiB Brotli but is low production usage. Both are better follow-up targets than expanding this review surface further.