API addwidget()

Dashboard
6

Dear all,

I will try to better explain my issue. You can easily reproduce it with a very basic flow made of on inject node and one linear graph. In the inject node you create a message send to the graph to display some points. You deploy it, you have a graph generated, everything is perfect.
Then you break the link between the inject node and the graph, you redeploy it, you have still points in the graph (last points sent previously ).
Is it a bug or feature to have some "persistent data" ? How can I remove this behavior ?

It's not a question of cache not cleaned because I see the request coming from the runtime when we redeploy the second time .

Thank you for your help.

7

Have you selected Full Deploy for the deploy button? Otherwise the chart node will not be restarted so it will still have the points stored.

8

Yes it's a full deploy

9

@Landry25 @BartButenaers Indeed I do confirm the behavior whatever the widget used : the standard ones from the dashboard, the @BartButenaers ones, or custom ...
Actually after a (re)deploy the runtime is sending back the last data (from previous deploy) over the websocket to the dashboard hence the concerned widgets are updated with the last data from previous deploy.
Don't know how to avoid the runtime to send back the data ...
Not sure either we can change this behavior with initController as the data are coming after initContoller has been executed ... the only "dirty" solution might be to cancel the data once they are received in a setTimeout in initController.

10

I think that if you set storeFrontEndInputAsState as false then it won’t save widget data, so would then have nothing to restore.

11

I already set the attribute storeFrontEndInputAsState as false in my widget and the behavior is not modified.

12

@dceejayIs the described behaviour what you would expect for the dashboard chart? I would have expected a Full Deploy to have cleared it.

13

Honestly can’t recall. Still on vacation

14

Yes of course, sorry.

15

I think only a stop start will clear it, not a deploy of any sort.

16

Few tests on my side, I do confirm :

  • storeFrontEndInputAsState as no effect on resending data at deploy either on my custom node nor on contrib ui nodes from npm (at least ui_level for @BartButenaers)
  • only stop start clear it as @dceejay said
17

The workaround is to send the chart an empty array on deploy.

18

Indeed but then it seems a bit weird to me to have such storeFrontEndInputAsState boolean with no effect

19

I would need to look at the code, but I suspect the bit i forgot is where it says FrontEnd. Ie it optionally stores state coming from the ui. I’d guess that indeed it stores everything coming from the back end, ie sent to the node.

20

Comments in index.js says clearly

       * [storeFrontEndInputAsState] - boolean (default true).
             If true, any message received from front-end is stored as state
21

Comments heh. Who would have thought ! ( but what does the code actually do ?...)

22

By just reading the code seems to me that
replayMessages object used for msg storage and filled on every input if there is something to emit. Socket has listener for ui-replay-state which seems to happen on new connection and then for every msg in replayMessages socket emits update-value
storeFrontEndInputAsState doesn't affect this behavior in any way

3 Likes
23

@dceejay @hotNipi I can do a PR on node-red-dashboard to add this behavior:
In order to keep existing behavior (and not break existing widget behavior) I propose to define a new boolean in addWidget API persistantFrontEndValue (default true).
When set to false, then update-value is not sent on new connection.
When set to true, keep existing behavior.

What do you think about such PR ?

24

@dceejay
Hello any feedback on the PR proposal is welcome.
I don't want to spend time on such dev if there is no chance to be considered/merged.
Thanks

25

PR done : https://github.com/node-red/node-red-dashboard/pull/558