RFC: Self-managing NewBadge / BetaBadge backed by an auto-expiring registry#48180
RFC: Self-managing NewBadge / BetaBadge backed by an auto-expiring registry#48180
Conversation
…g registry Adds `lib/new-features` (registry + `useNewFeature` hook) and `components/new-badge` (`<NewBadge>` / `<BetaBadge>`) to plugins/jetpack as a proof-of-concept for an alternative pattern: instead of inline `<Badge>New</Badge>` plus a TODO that rots, consumers write `<NewBadge feature="jetpack-ai" />` and the badge silently disappears once its registered window expires. Registry edits, not code edits, drive the lifecycle. Migrates the writing/composing.jsx AI Assistant badge as the demo consumer — replacing the Chip + 21-month-old TODO comment from #38414 with a single self-managing component. Scoped to plugins/jetpack to keep the proposal small and reviewable.
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 🔴 Action required: Please include detailed testing steps, explaining how to test your change, like so: 🔴 Action required: We would recommend that you add a section to the PR description to specify whether this PR includes any changes to data or privacy, like so: Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
| } | ||
| return ( | ||
| <Badge intent="stable"> | ||
| { _x( 'New', 'Indicates a recently-launched feature.', 'jetpack' ) } |
There was a problem hiding this comment.
Does, text need to be customizable?
| * @return The Badge, or null when the feature isn't flagged or has expired. | ||
| */ | ||
| export function BetaBadge( { feature }: Props ) { | ||
| if ( ! useNewFeature( feature, 'beta' ) ) { |
There was a problem hiding this comment.
Beta might need to be something that is not expirable and automatically hidden, since usually that is usually manually decided. Still with the registry, we could at least automate some sort of check for pinging folks if a beta thing sits at beta for "x" time period after the set "expiry"
| * @param props.feature - Slug registered in `lib/new-features`. | ||
| * @return The Badge, or null when the feature isn't flagged or has expired. | ||
| */ | ||
| export function NewBadge( { feature }: Props ) { |
There was a problem hiding this comment.
I wonder if expiry should just be a prop. Then we could likely more easily automate some sort of code cleanup action on every Jetpack release to get rid of expired badges direclty in the code.
| export const NEW_FEATURES: readonly NewFeatureEntry[] = [ | ||
| { | ||
| slug: 'jetpack-ai', | ||
| addedAt: '2024-07-22', | ||
| durationDays: 365, | ||
| note: 'AI Assistant entry link added in #38414. Flagged retroactively to demo the registry pattern.', | ||
| }, | ||
| ]; |
There was a problem hiding this comment.
As noted in a separate comment, I'm not sure about the registry pattern (and instead maybe include that via props on the actual badge wrapper component).
Code Coverage Summary2 files are newly checked for coverage.
Full summary · PHP report · JS report If appropriate, add one of these labels to override the failing coverage check:
Covered by non-unit tests
|
Proof-of-concept / RFC. Not for merge as-is. See #48162 for the actual Chip migration.
Problem
<Badge>New</Badge>plus a// TODO: remove once not "new"comment is the standard pattern. Those TODOs rot — the one this PR replaces incomposing.jsxwas added in #38414 in July 2024 (21 months ago).Proposal
Drive "New"/"Beta" badges from a tiny per-plugin registry that auto-expires entries:
<NewBadge>and<BetaBadge>consumeuseNewFeature(slug)which checks the registry + the date window and returnsnullwhen the feature isn't flagged or the window has elapsed. No consumer change needed when a feature ages out — registry edits drive the lifecycle.What's in this PR
_inc/client/lib/new-features/index.ts— registry, types,useNewFeaturehook_inc/client/components/new-badge/index.tsx—<NewBadge>and<BetaBadge>composing.jsxmigrated from<Chip type="new" text={...} />+ the 21-month TODO →<NewBadge feature="jetpack-ai" />Out of scope
<Pill>, Protect badges) — would follow if the pattern is approved.<NewBadge>/<BetaBadge>tojs-packages/components— defer until the pattern proves itself in one plugin.Looking for
Yes/no on the pattern. Bikeshed on the registry shape (date-based vs. version-based expiry, where it lives, whether to also gate via PHP).
Related