# Refresh ui-node
**URL:** https://discourse.nodered.org/t/refresh-ui-node/13921
**Category:** Dashboard
**Created:** [2 August 2019 09:16 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921 "2019-08-02T09:16:49Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@fellinga](https://discourse.nodered.org/u/fellinga)
#### Post date: [2 August 2019 09:16 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/1 "2019-08-02T09:16:49Z")
Hello,
I am developing a node that lets the user modify an incoming msg.payload via the UI (html table).
By clicking the "save" button - this payload is being sent to the output. This works great so far and the user can see all the changes in the UI.
But here's the problem:
Refreshing the page causes the table to restore the msg.payload that came in before it was modified. How can I update the internals of my node while saving?
BTW: Connecting the (my-node) output to a function node and the function node to the (my-node) input solves the problem - but that's not pretty.
Thanks!
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [2 August 2019 10:32 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/2 "2019-08-02T10:32:22Z")
What do you do with the new value?
---
### Author:  [@shrickus](https://discourse.nodered.org/u/shrickus)
#### Post date: [3 August 2019 14:23 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/3 "2019-08-03T14:23:31Z")
Put a change event handler on each cell of your table, sending the new value every time it is updated. No need to wait and send the whole row of data using a Save button.
The better examples I've seen even use css tricks to provide instant feedback, like setting a background color to green on success, or red on failure.
---
### Author:  [@fellinga](https://discourse.nodered.org/u/fellinga)
#### Post date: [4 August 2019 07:55 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/4 "2019-08-04T07:55:33Z")
@shrickus the save button is a 'feature'. The user has to finish before sending the complete data. The whole html/css part already works perfectly, I do show changes with colors and values inside the table data. The table shows changes live and even after clicking send the table contains the modified data (the outgoing payload is fine as well).
But hitting the F5 key will reset the table to the start state, that's the issue here.
---
### Author:  [@afelix](https://discourse.nodered.org/u/afelix)
#### Post date: [4 August 2019 09:19 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/5 "2019-08-04T09:19:37Z")
But, from an interface perspective refresh not saving changes makes sense. After all, actions might have been taken but the safe button hasnโt been pressed. Thus should from that perspective refresh result in showing the unchanged data from before the editing (aka refresh resulting in undoing the changes), or should refresh result in showing changed data that isnโt saved yet, and if so what makes pressing the save button special?
Is your kind of user intuitively going to expect refresh means changed even without saving, as it is something that differs from most implementations out there in the real world. Like I understand why you want this to happen, but have you thought about wanting it for the right reasons and does it match the logical progression of your interface design.
---
### Author:  [@fellinga](https://discourse.nodered.org/u/fellinga)
#### Post date: [4 August 2019 23:18 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/6 "2019-08-04T23:18:39Z")
@afelix ok.. so maybe I wasn't very specific about the actual issue.
Current status:
1. Changing the data -\> not saving the data -\> F5 = old values
------- This should be like this and is ok right now
2. Changing the data -\> not saving the data -\> leaving the page -\> return later = old values
------- This should be like this and is ok right now
3. Changing the data -\> saving the data (new payload is being sent to the output) -\> F5 = old values
------- This should not be like this and is the only problem here
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [5 August 2019 06:04 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/7 "2019-08-05T06:04:32Z")
This is about same problem as in this thread [API addwidget()](https://discourse.nodered.org/t/api-addwidget/13604)
Conclusion is - On redeploy/refresh the API resend last incoming payload.
As you can't change this behavior, you should respect it and build your widget to follow the underlying logic.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [5 August 2019 07:24 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/8 "2019-08-05T07:24:35Z")
If storeFrontEndInputAsState is true then the state should be updated with the new value, so a refresh should then have the latest value.
---
### Author:  [@fellinga](https://discourse.nodered.org/u/fellinga)
#### Post date: [5 August 2019 11:00 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/9 "2019-08-05T11:00:14Z")
@dceejay I have tried this setting already and I wasn't sure if I need to add something else as well.
Changing storeFrontEndInputAsState from false to true, clears the table completely after "saving" and I have to manually inject a new payload to get it back. I am using "\
### Author:  [@fellinga](https://discourse.nodered.org/u/fellinga)
#### Post date: [6 August 2019 19:03 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/10 "2019-08-06T19:03:25Z")
@hotNipi Well, I think resending the last incoming payload is not bad at all and I respect the underlying logic.
I just thought that there is a possibility to programmatically send a msg to the input inside the myUiNode.js.
Especially because it is quite easy to fix by adding a function node:
---
### Author:  [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)
#### Post date: [2 October 2019 22:17 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/11 "2019-10-02T22:17:25Z")
> [@dceejay](#):
>
> If storeFrontEndInputAsState is true then the state should be updated with the new value, so a refresh should then have the latest value.
Hey guys,
@Steve-Mcl and myself have a very annoying [issue](https://github.com/bartbutenaers/node-red-contrib-ui-contextmenu/issues/9) with our [contextmenu](https://discourse.nodered.org/t/announce-node-red-contrib-ui-contextmenu-first-beta/16211/4) node.
Summarized:
1. you click on a clickable shape in our new SVG node
2. an **output message** is being send (incl. X/Y coordinates) to our contextmenu node
3. the contextmenu node displays a menu at the location (specified in the input message)
4. you click somewhere else in the dashboard, so the context menu **disappears**
5. you deploy something.
6. now suddenly the last input message is received again, so we display the contextmenu AGAIN....
Does anybody have a tip to avoid the last input message being repeated?
We have played with the `storeFrontEndInputAsState ` value but that doesn't help ๐ฅด
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [2 October 2019 22:31 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/12 "2019-10-02T22:31:40Z")
Bart, did we try setting [this parameter](https://github.com/bartbutenaers/node-red-contrib-ui-contextmenu/blob/14da2f2ba351cf69fb4fe3c164c09b8f845293c5/context_menu.js#L69) to `true`?
Re reading that comment makes me think we should give it a try?
---
### Author:  [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)
#### Post date: [2 October 2019 22:33 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/13 "2019-10-02T22:33:33Z")
I think I have tried this about 350 times ๐
But will try it again for last time tomorrow ...
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [3 October 2019 04:02 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/14 "2019-10-03T04:02:29Z")
May be something like this may work:
Add time (when click was made) to the msg.payload
At the contextmenu ignore incoming messages where time is older than (choose acceptable time)
---
### Author:  [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)
#### Post date: [4 October 2019 07:06 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/15 "2019-10-04T07:06:28Z")
Morning @hotNipi,
I didn't have time yet to test your proposal, but I'm wondering if we simply could do it like this:
```auto
$scope.$watch('msg', function(msg) {
// Ignore undefined messages.
if (!msg) {
return;
}
// Avoid messages being handled twice. Otherwise messages will be replayed after a deploy, causing animations to be started automatically
if (msg.alreadyHandled) {
return;
}
msg.alreadyHandled = true;
...
}
```
Or do you really think (based on your experience) we need to work with a timestamp? Is this perhaps because we need to allow the **same** message to be handled multiple times during a (short) time period, e.g. because AngularJs calls the watch multiple times anyway?
Thanks !!
Bart
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [4 October 2019 07:39 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/16 "2019-10-04T07:39:17Z")
I think the unwanted replaymessage should be filtered in `beforeEmit`.
If you change message properties the [node-red-dashboard](https://github.com/node-red/node-red-dashboard)/ **ui.js** does not know about this change unless you send the message back to the server side. Then you can take advantage of `storeFrontEndInputAsState` parameter. Haven't tested but just reading the code it should work like this.
from ui.js :
```auto
// This is the handler for messages coming back from the UI
var handler = function (msg) {
if (msg.id !== opt.node.id) { return; } // ignore if not us
if (settings.readOnly === true) {
msg.value = currentValues[msg.id];
} // don't accept input if we are in read only mode
else {
var converted = opt.convertBack(msg.value);
if (opt.storeFrontEndInputAsState === true) {
currentValues[msg.id] = converted;
replayMessages[msg.id] = msg;
```
Should do some test on this. I'm not sure ..
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [4 October 2019 08:40 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/17 "2019-10-04T08:40:00Z")
So
_I think the unwanted replaymessage should be filtered in `beforeEmit`_ \<-- wrong. socket emits what is stored. `beforeEmit` is in use only with new incoming messages.
I did this and it nearly does the trick
```auto
$scope.$watch('msg', function (msg) {
if (!msg) {
return;
}
if(msg.handled && msg.handled == true){
console.log('scope already hanlded',msg)
return
}
console.log('scope fresh msg',msg)
var m = { }
m.payload = 'ignore me'
m.topic = msg.topic
m.handled = true
$scope.send(m)
// do your stuff with msg
});
```
What is wrong about this is that you'll get always that second message back to scope
normal run:
after deploy:
I think proper way is to introduce flag for ui-node's indicating that socket should not send replaymessage.
---
### Author:  [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)
#### Post date: [4 October 2019 11:11 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/18 "2019-10-04T11:11:45Z")
> [@hotNipi](#):
>
> to introduce flag for ui-node's
Is this something we can do ourselves in our nodes, or do we need to call @dceejay. Alias 'the master' (of disaster ๐)
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [4 October 2019 11:34 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/19 "2019-10-04T11:34:12Z")
It is decision for master to even accept the proposal or deny. By looking the code it is a bit more than just "introduce a flag" thing. Needs some deeper analyse and testing but I'm a bit too busy to fit it right away into my near schedule.
EDIT: overall there may be other ways also to get it and we just not smart enough to find it ๐
---
### Author:  [@hotNipi](https://discourse.nodered.org/u/hotNipi)
#### Post date: [4 October 2019 12:36 UTC](https://discourse.nodered.org/t/refresh-ui-node/13921/20 "2019-10-04T12:36:10Z")
Possible workaround:
As you can not ignore first message always (it may be correct message) make your own first message
```auto
$scope.init = function(config){
$scope.acceptIncomingMessages = false
//do your regular init phase stuff
//send init message
var initmessage = {payload:"init-"+$scope.unique}
$scope.send(initmessage)
}
$scope.$watch("msg", function (msg) {
if (!msg) {
return;
}
if(msg.payload == "init-"+$scope.unique){
console.log("scope msg - init",msg)
$scope.acceptIncomingMessages = true
return
}
if($scope.acceptIncomingMessages == false){
console.log("scope msg - no way ",msg)
return
}
console.log("scope msg - passed",msg)
//continue here with all good messages passed
}
```
Replay message will be sent before your first message and will be ignored.
[Next page](https://discourse.nodered.org/t/refresh-ui-node/13921.md?page=2)