feat: Implements the action bar with core actions.#393
feat: Implements the action bar with core actions.#393kozmaadrian wants to merge 2 commits intoewfrom
Conversation
The action buttons in the modal have the wrong font family (maybe the variable isn't set there for some reason?) |
|
I think we should separate preview and publish as actions. As an edge delivery user, that's what I'm used to. Only having a publish button makes it not clear to me whether it will do preview, publish or preview -> publish both. |
|
Happy to debate this one, but: Do we really need a confirmation dialog for single-file preview/publish? For multi files it makes sense, but for single file, we don't have a confirmation in sidekick or da so I don't think we need it here. |
Currently if the url has a hash or a query param, that is also part of the browse title and breadcrumb. Would be good to sanitize so these stay meaningful.
|
| variant: { type: String, attribute: false }, | ||
| autofocusId: { type: String, attribute: false }, | ||
| dismissable: { type: Boolean, attribute: false }, | ||
| onPrimaryAction: { type: Function, attribute: false }, |
There was a problem hiding this comment.
Why do we go for this approach vs firing events as in other blocks? This creates tight coupling between consumer and dialog, when ideally it would be nice that dialog simply fires an event and consumer listens and responds - consistent with how things are working across the repo atm. Dialog doesnt and shouldnt know about what happens after click - it just handles the UI, fires event and forgets, and everything else is the responsibility of the consumer.
As a bonus, this would also help redice the properties ie both the onAction and the actionId
|
@kozmaadrian All new blocks introduced have the callback pattern as in React vs event driven pattern across the repo. Why this deviation from pattern? |
|
|
||
| _renderShell({ title, body, actions }) { | ||
| return html` | ||
| <div |
There was a problem hiding this comment.
Worth exploring if we can use the native api here instead of custom code completely - it would give ootb support for many of the expected capabilities of a dialog.
There was a problem hiding this comment.
+1, this should use dialog with showModal
3 participants
Implements the action bar with core actions: preview, publish, delete, and rename.
Also adds shared components dialog, toast, and progress circle, required for the browse actions.
Test URLs: