# Formatting ui-notification
**URL:** https://discourse.nodered.org/t/formatting-ui-notification/90348
**Category:** Dashboard
**Tags:** dashboard-2
**Created:** [22 August 2024 20:44 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348 "2024-08-22T20:44:44Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [22 August 2024 20:44 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/1 "2024-08-22T20:44:44Z")
Anyone had any luck in formatting the Dashboard 2 ui-notification overlay?
Using it on a phone with grid size 12x12, the overlay is too wide to be displayed correctly, cutting off the text, and the 'Cancel' - 'Confirm' text would be more intuitive if they were buttons instead of text links.
Dashboard v1.15.0
```auto
[{"id":"b5f2a639b7d19b66","type":"ui-button","z":"be4568a984cb4685","group":"3037a2992d27ef33","name":"Button 1","label":"Driveway","order":2,"width":"4","height":"1","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"click","payloadType":"str","topic":"button1","topicType":"str","buttonColor":"","textColor":"","iconColor":"","x":320,"y":1760,"wires":[["c4a2394d758d7565"]]},{"id":"c4a2394d758d7565","type":"ui-notification","z":"be4568a984cb4685","ui":"ae3d4aeb3f977a90","position":"top center","colorDefault":true,"color":"#000000","displayTime":"5","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Cancel","allowConfirm":true,"confirmText":"Confirm","raw":false,"className":"","name":"Confirm","x":480,"y":1760,"wires":[["dc147f8bd7854b78"]]},{"id":"dc147f8bd7854b78","type":"function","z":"be4568a984cb4685","name":"Change status","func":"if (msg.payload == \"confirm_clicked\") {\n var buttons_status = flow.get('buttons') || \"off\"\n switch (buttons_status) {\n case \"on\":\n node.send({payload: \"off\"})\n buttons_status = \"off\"\n break;\n case \"off\":\n node.send({payload: \"on\"})\n buttons_status = \"on\"\n break;\n default:\n node.warn(\"Status not matched!\");\n break;\n }\n flow.set('buttons', buttons_status)\n}\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":660,"y":1760,"wires":[["af7ec95ad0c6445c"]]},{"id":"af7ec95ad0c6445c","type":"change","z":"be4568a984cb4685","name":"Change color","rules":[{"t":"change","p":"payload","pt":"msg","from":"on","fromt":"str","to":"#F44336","tot":"str"},{"t":"change","p":"payload","pt":"msg","from":"off","fromt":"str","to":"#A7FFEB","tot":"str"},{"t":"set","p":"ui_update.buttonColor","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":490,"y":1820,"wires":[["b5f2a639b7d19b66"]]},{"id":"3037a2992d27ef33","type":"ui-group","name":"Lighting","page":"7294756f31e17b81","width":"12","height":"12","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"ae3d4aeb3f977a90","type":"ui-base","name":"Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"showPageTitle":true,"navigationStyle":"temporary","titleBarStyle":"hidden"},{"id":"7294756f31e17b81","type":"ui-page","name":"Security","ui":"ae3d4aeb3f977a90","path":"/security","icon":"home","layout":"grid","theme":"52ba8a01d6eda628","order":1,"className":"","visible":true,"disabled":false},{"id":"52ba8a01d6eda628","type":"ui-theme","name":"Mobile","colors":{"surface":"#ffffff","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"compact","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
```
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [23 August 2024 05:57 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/2 "2024-08-23T05:57:28Z")
```auto
.v-snackbar__wrapper{
min-width: 200px;
}
```
Can also use media query to apply sizing rules only for small screens and so on
---
### Author:  [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)
#### Post date: [23 August 2024 07:51 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/3 "2024-08-23T07:51:29Z")
> [@hotNipi](#):
>
> Can also use media query to apply sizing rules only for small screens and so on
If your holidays ever ends and CSS is going upwards again in your priority list, that might be a very useful pull request 😇
---
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [23 August 2024 08:14 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/4 "2024-08-23T08:14:16Z")
That's made the width much better, thanks @hotNipi
It's a long time since I used the original Dashboard, but wasn't the Cancel/Confirm interactions actual buttons, which made it clear that one should be selected.
Also, can't we get rid of the incoming payload message - top left - 'click' in my screenshot, when the ui-notification is used for this purpose?
---
### Author:  [@joepavitt](https://discourse.nodered.org/u/joepavitt)
#### Post date: [23 August 2024 09:19 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/5 "2024-08-23T09:19:44Z")
Can you raise an issue for this please @Paul-Reed - this shouldn't be the default behaviour
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [23 August 2024 09:20 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/6 "2024-08-23T09:20:07Z")
> [@Paul-Reed](#):
>
> if they were buttons instead of text links.
They are buttons, (you can style them with a different color)
> [@Paul-Reed](#):
>
> Also, can't we get rid of the incoming payload message - top left - 'click' in my screenshot, when the ui-notification is used for this purpose?
Set payload to empty string.
---
### Author:  [@joepavitt](https://discourse.nodered.org/u/joepavitt)
#### Post date: [23 August 2024 09:20 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/7 "2024-08-23T09:20:20Z")
> [@Paul-Reed](#):
>
> but wasn't the Cancel/Confirm interactions actual buttons, which made it clear that one should be selected.
Also open to changing this too, feel free to open a (second) issue/feature request
---
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [23 August 2024 10:45 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/8 "2024-08-23T10:45:11Z")
> [@Steve-Mcl](#):
>
> They are buttons, (you can style them with a different color)
Thought they were text links... I did check the documentation for styling, but there's no info there.
> [@Steve-Mcl](#):
>
> Set payload to empty string.
I realise that, but maybe the payload is needed further in the flow. In any event shouldn't there be an optional name property, like other UI nodes, so we could enter text instead of showing the payload, so for example we could enter " Please confirm action" (and yes I know I could inject that text as a payload 😏)
> [@joepavitt](#):
>
> feel free to open a (second) issue/feature request
Will do when I return home.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [23 August 2024 11:00 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/9 "2024-08-23T11:00:19Z")
> [@Paul-Reed](#):
>
> > [@Steve-Mcl](#):
> >
> > Set payload to empty string.
>
> I realise that, but maybe the payload is needed further in the flow. In any event shouldn't there be an optional name property, like other UI nodes, so we could enter text instead of showing the payload, so for example we could enter " Please confirm action" (and yes I know I could inject that text as a payload 😏)
Yep. This is a prime candidate for a typed input to permit either `string` or `msg.` IMO but then I feel that way about ALL nodes (I hate having to put change nodes everywhere!). There is an open issue somewhere on dashboard about permitting user choice when it comes to where the payload comes from but I am told there are difficulties implementing this on dashboard.
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [23 August 2024 12:57 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/10 "2024-08-23T12:57:10Z")
It ends when you tear off the August from calendar... But I'm still nearby 😃
---
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [23 August 2024 13:49 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/11 "2024-08-23T13:49:15Z")
Issues raised as requested -
>
>
> When using the ui-notification on a small device such as a phone, the overlay is… wider than the phone screen, cutting off text.
>
> \
>
> However, as @hotNipi has suggested, this could be controlled by applying a css overide;
>
> \`\`\`
> .v-snackbar\_\_wrapper{
> min-width: 200px;
> }
> \`\`\`
>
> Which results in...
>
> \
>
> Could this be applied as a default?
>
> Dashboard v1.15.0
>
>
> I believe that in the original Dashboard, the \`Cancel / Confirm\` buttons were di…splayed as actual buttons, instead of what looks like text links.
>
> \
>
> If these are actual buttons, could the default be that they adopt the current colour theme, so that they look like buttons, and if users want something different, then let them overide the default via css?
>
> Dashboard v1.15.0
>
>
> Instead of the ui-notification displaying the incoming msg top left of the overl…ay, could there be an optional name property, like other UI nodes, so we could enter text instead of showing the payload, so for example we could enter " Please confirm action" as a string.
> Also... if the user selects 'string', and the field is left blank, then the space that the string would have occupied, could be removed, which would reduce the height of the the overlay, making it look less intrusive. (...if that makes sense!!)
>
> During a \[forum discussion\](https://discourse.nodered.org/t/formatting-ui-notification/90348/9), @Steve-Mcl suggested that having a typed input would enable users to select either the msg or a string, but warned that it may not be possible??
>
> \
>
> Dashboard v1.15.0
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [23 August 2024 14:33 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/12 "2024-08-23T14:33:26Z")
I see the node passes the incoming message through. Is that intentional? I can't see any reason to do that.
---
### Author:  [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)
#### Post date: [23 August 2024 15:05 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/13 "2024-08-23T15:05:28Z")
> [@Steve-Mcl](#):
>
> This is a prime candidate for a typed input to permit either `string` or `msg.`
For me this is currently the (last) confusing part of ui node development for D2.
All properties from the config screen arrive via ´props´ on the frontend, and you can override those values via properties in the ´msg.ui\_update´. Everything is nicely stored in the state store. And you have a ´getProperty´ function that contains the logic to return the original or overridden value. That all works like a charm out of the box. Really nice for developers.
However on the other hand there is _ **"the value"** _ of the widget. This is not available on the config screen, but is injected via the ´msg.payload´ and stored in the data store. For simple widgets it is clear what the value is. E.g. for a text-input-ui it is the text value. But for a complex svg drawing? And for the ui-notification it is the displayed text. But if you want both a text content and a title in the notification. Or if you want to have a typedinput on your config screen with a _default value_, which can alsi be overridden as a dynamic property. In that case you need to start mixing data from the data store and state store, which makes it complex again.
Imho that separate data store for messages makes these things complex.
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [24 August 2024 09:37 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/14 "2024-08-24T09:37:30Z")
Should the node save any extra properties from the incoming message and attach them to the outgoing? For me this would be useful. For example, I have a flow that builds a message from user input which is to be sent to influxdb, I want to put a Confirm/Cancel notification in, but doing that would lose the additional properties so I have to add additional stuff to save and restore them.
---
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [24 August 2024 10:27 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/15 "2024-08-24T10:27:18Z")
> [@Colin](#):
>
> Should the node save any extra properties from the incoming message and attach them to the outgoing?
Yes agree!
I hit the same thing yesterday whilst trying to re-use one ui-notification node for a number of different inputs, but partly solved it by using `msg.topic`, which is carried forward from it's input.
I don't find the outputs - `confirm_clicked`, `dismiss_clicked` or `timeout` as a payload are particularly useful, as well as usually needing a switch node thereafter to distinguish between them, and maybe also a change node for the payload msg to be of some value.
Why would we need an output to tell us `dismiss_clicked` or `timeout` had occurred?
Struggling to remember, but didn't the original Dashboard ui node only pass an output when 'confirm' had been selected, and then passed through the incoming msg? That would be more useful and workable IMO.
I was tempted to raise an issue for this yesterday, but having already raised 3, I thought better of it... 😉
---
### Author:  [@Bobo](https://discourse.nodered.org/u/Bobo)
#### Post date: [24 August 2024 10:47 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/16 "2024-08-24T10:47:43Z")
Since it's Saturday night I thought I'd join the party.
Here is what I requested a few weeks ago. [Ui-notification allow pass-through via on-click event](https://discourse.nodered.org/t/ui-notification-allow-pass-through-via-on-click-event/89828)
I'm confused about the above convo. Hasn't this been done in the latest revision? I haven't had a chance to try it yet.
---
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [24 August 2024 11:37 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/17 "2024-08-24T11:37:02Z")
> [@Bobo](#):
>
> Hasn't this been done in the latest revision?
Nope, what happens now is that we get 2 msg's, the first is the original pass through msg (for some reason?), but when confirm is selected we get a second msg with a payload of confirm\_clicked.
Try it yourself & see.
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [24 August 2024 12:40 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/18 "2024-08-24T12:40:15Z")
> [@Paul-Reed](#):
>
> Why would we need an output to tell us `dismiss_clicked` or `timeout` had occurred?
> Struggling to remember, but didn't the original Dashboard ui node only pass an output when 'confirm' had been selected, and then passed through the incoming msg?
With the D1 notification node I don't think there is a timeout return, at least it isn't documented in the help text. I can imagine that could be useful though. The timeout is disabled in the case of OK/Cancel mode with D1, but I don't know why that is the case. It should be up to the user to decide.
With D1, when a button is clicked the text of the button itself is returned, so it is up to the user whether the buttons are ok/cancel or just two independent options, and which button is which. I think there is an argument for keeping this compatibility with D1. The Switch will still generally be necessary, but what it is doing is clearer as it will refer to the button text which will probably be self explanatory. I suppose the node could have three outputs, one for each button and one for timeout, that would remove the requirement for the switch.
A minor issue, the fact that the timeout can be disabled by setting to 0 or blank does not appear to be mentioned in the help text.
---
### Author:  [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)
#### Post date: [24 August 2024 13:56 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/19 "2024-08-24T13:56:36Z")
> [@Colin](#):
>
> Switch will still generally be necessary
If the only output was provided when 'confirm' was selected, and it was the payload from the button, there may be no need for a switch or change node.
> [@Colin](#):
>
> ...three outputs, one for each button and one for timeout, that would remove the requirement for the switch.
Couldn't we just have 2 outputs;
1. passes through the msg from the button, ONLY WHEN and IF the confirm button is selected.
2. all remaining msg's originating from the notification node itself. ie `confirm_clicked`, `dismiss_clicked` & `timeout`
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [24 August 2024 14:09 UTC](https://discourse.nodered.org/t/formatting-ui-notification/90348/20 "2024-08-24T14:09:36Z")
> [@Paul-Reed](#):
>
> Couldn't we just have 2 outputs;
If we were to go to the effort of providing 2 outputs then we might as well provide all three. What is the advantage of just providing the two?
[Next page](https://discourse.nodered.org/t/formatting-ui-notification/90348.md?page=2)