Adding snackbar notices support to the new widgets page #16020
Conversation
| import { SnackbarList } from '@wordpress/components'; | ||
| import { useSelect, useDispatch } from '@wordpress/data'; | ||
|
|
||
| function Notices() { |
There was a problem hiding this comment.
This made me wonder if we want to move the EditorNotices component from the editor package to the notices package as we'd have to rewrite such component for each consumer.
There was a problem hiding this comment.
Yes, I guess it would be good to avoid this code repetition and just expose the component as part of the notices package.
| __( 'Block areas saved succesfully.' ), | ||
| { | ||
| id: WIDGET_AREAS_SAVE_NOTICE_ID, | ||
| type: 'snackbar', |
There was a problem hiding this comment.
I wondered whether the "context" argument should be used here to differentiate between the "post editor" notices and the "widget screen" notices. Imagine a world where the WP-Admin is a full SPA, do we want to use this context to differentiate between these notices?
Also depending on the answer, this raises the question of whether we should set a default context to "post editor" for existing plugins creating notices in the editor.
There was a problem hiding this comment.
Hi @youknowriad, you mean the context for translation right? If yes even if we a are in a full SPA I don't think we need context to differentiate between screens. WordPress did not used different contexts if two strings were on different screens so I think we can follow the same logic.
There was a problem hiding this comment.
no, I meant the "context" property of the notices (we never used it but the API supports it). cc @aduth as we discussed some of this recently.
youknowriad
added
the
[Feature] Widgets Screen
There was a problem hiding this comment.
Things worked great in my tests, thank you for this important UX improvement 👍 I guess the would be good to a avoid the need to implement the notices component as part of this package (packages/edit-widgets/src/components/notices/index.js), but I'm ok with that refactored being performed in a different PR.
| import { SnackbarList } from '@wordpress/components'; | ||
| import { useSelect, useDispatch } from '@wordpress/data'; | ||
|
|
||
| function Notices() { |
There was a problem hiding this comment.
Yes, I guess it would be good to avoid this code repetition and just expose the component as part of the notices package.
| args: [ | ||
| 'Block areas saved succesfully.', | ||
| { | ||
| id: 'WIDGET_AREAS_SAVE_NOTICE_ID', |
There was a problem hiding this comment.
Nit pick: Maybe the test can import WIDGET_AREAS_SAVE_NOTICE_ID as a constant from the actions file.
There was a problem hiding this comment.
It's not exported at the moment. I mean I could export it but for a test, maybe it's not that important.
|
I tested, and from a design perspective, it looked great. |
I may have missed it, but wanted to verify there was agreement on the time the snackbar remained visible before dismissing itself. I love these little notifications animating into view!
jorgefilipecosta
moved this from Widget screen UI issues
to Core/Extensibility/API tasks
in Block-based Widgets Editor
jorgefilipecosta
moved this from Core/Extensibility/API tasks
to Done
in Block-based Widgets Editor
This PR adds a "save success" snackbar notice to the new widgets page. It's also the first PR adding support for the notices to the widgets screen which raises a bunch of interesting questions :)
Testing instructions