Refresh ui-node


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.


What do you do with the new value?

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.

@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.

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.

@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

This is about same problem as in this thread API addwidget()
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.


If storeFrontEndInputAsState is true then the state should be updated with the new value, so a refresh should then have the latest value.

1 Like

@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 "<tr ng-repeat="n in msg.payload[0] track by $index" ....".

@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: