I'm using the API addwidget() to create a dashboard node (graph) , and I don't know why but when I re-deploy my flow, or when I refresh the page , I have the last point which seems to be sent again by the backend . So I would know if it's possible to listen specific event (similar to "nodes-started") with this addwidget() API, to clear the graph after a redeploy.
Hi @Landry25,
Can't you do that in the initController function?
ui.addWidget({
...
initController: function($scope, events) { .. }
…
})
Bart
Thank you. I'm not sure to understand how it's working, do you have some examples ?
I'm afraid also this initcontroller will be called too early , and the points are sent after initialization of the graphical part. But I have a to try.
Landry
The number of UI nodes is reather rather limited:
- GitHub - Adorkable/node-red-contrib-ui-led: A simple LED status indicator for the Node-RED Dashboard
- GitHub - hotNipi/node-red-contrib-ui-level: A linear level type widget to the Node-RED dashboard
- GitHub - node-red/node-red-ui-nodes: Additional nodes for Node-RED Dashboard
- GitHub - bartbutenaers/node-red-contrib-ui-heatmap: A Node Red node to show a heat map
- …
This is not clear to me. I propose you share some of your code, so people can try to understand what is going wrong. Otherwise we can only guess what is going wrong. E.g. do you store the graph points on the Angular scope?
Do you mean every deploy and no matter if your widget configuration is changed or not? I don't think it is good idea to create such connection between absolutely not related events. Look and feel and behavior of graphical widgets should depend on configuration and incoming data only.
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.
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.
Yes it's a full deploy
@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.
I think that if you set storeFrontEndInputAsState as false then it won’t save widget data, so would then have nothing to restore.
I already set the attribute storeFrontEndInputAsState as false in my widget and the behavior is not modified.
@dceejayIs the described behaviour what you would expect for the dashboard chart? I would have expected a Full Deploy to have cleared it.
Honestly can’t recall. Still on vacation
Yes of course, sorry.
I think only a stop start will clear it, not a deploy of any sort.
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
The workaround is to send the chart an empty array on deploy.
Indeed but then it seems a bit weird to me to have such storeFrontEndInputAsState boolean with no effect
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.
Comments in index.js
says clearly
* [storeFrontEndInputAsState] - boolean (default true).
If true, any message received from front-end is stored as state