Repository navigation
UI: Recommend Notice component - #82685
Conversation
🤖 PR meta 🤖📦 Bundle sizeSize Change: 0 B Total Size: 8.25 MB
⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
|
ciampo
left a comment
There was a problem hiding this comment.
LGTM 🚀
Side question: should we also mark components as "Not recommended" (and point out the substitutes) in each README file?
|
|
||
| ### Enhancements | ||
|
|
||
| - `Notice`: Mark as not recommended in favor of `Notice` from `@wordpress/ui`. |
There was a problem hiding this comment.
Missing PR reference, here and in every CHANGELOG entry in this PR
There was a problem hiding this comment.
Missing PR reference, here and in every CHANGELOG entry in this PR
👍 Updated in 0027ed1.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Yes, probably. I'll plan to address that in a fast follow-on to apply to all of the non-recommended components. It might also be good to include this in some written documentation around what steps need to be taken to mark a component as recommended. This was something I had my AI agent verify before starting with this and we don't really have any canonical documentation at the moment. A side-side question could be in regard to how we think about README in relation to published Storybook documentation, where we keep this source of truth, and whether we should even have non-recommended components in Storybook. |
|
At the risk of self-imposing blockers, I wonder if we should sort out #82701 before marking this as recommended, per my own points at #82611 (comment) of recommendation being a signal of API stability. Or perhaps we can accept that API stability should be detached from encouraging component adoption. My main reason to pause would be that #82701 would be easier to address before wide-scale adoption if we can understand how spoken messages should be announced at the time of migration, rather than retroactively through an audit. |
|
If #82701 can be wrapped up soon, it's probably worth the wait |
|
If we go with something similar to what I proposed in #82701 (comment), I think the main blocker to stabilization would be removing the default spoken announcements (what you're already exploring in #82737). This would avoid a situation where developers could become dependent upon the existing announcement behavior and requiring us to audit and migrate such usage. Then, whatever abstraction we come up with for the live region announcements would be an additional, separate enhancement to make it easier to implement live notice announcements the correct way. |
|
Sounds good, I'll work on #82737 and mark it as ready for review soon. |
|
With #82737 since being merged, I think it unblocks this and I'll plan to refresh and merge soon. |
c3aca70 to
b41eb56
Compare
00a7e37 to
d7e704e
Compare
d7e704e to
f9be9fd
Compare
* UI: Recommend Notice component * Remove Notice from caution list Co-authored-by: aduth <aduth@git.wordpress.org> Co-authored-by: ciampo <mciampini@git.wordpress.org>
What?
Updates component recommendations so that
@wordpress/ui'sNoticeis recommended over the component from@wordpress/components.Part of #76135
Why?
All known blockers to readiness have been resolved.
The last known blocker was its internal dependency on the
Buttoncomponent which is used in presenting actions. Based on #76135 (comment), the Button component itself is effectively ready, absent some migration documentation.How?
tagsandstatusfor each version of the component to mark@wordpress/uiimplementation as the recommended optionTesting Instructions
Verify that each component's status is reflected accurately in Storybook via
npm run storybook:dev.Bonus points:
@wordpress/componentsNoticelocally in a code path and verify lint errorUse of AI Tools
Used Cursor IDE + Auto model to implement, verified manually.