I haven't worked (real paid work I mean) on solutions where state of something is/should be stored. (except user choice of something very trivial which goes to localstorage)
Here the dashboard 1 & 2 both offer that. I have been living with that (fighting a lot when creating widgets) but for myself I still created dashboard with classical "request-response / register" solution. I do understand it and it is as reliable as the socket connection can be (and quality of my coding).
But there's not much choice here. It is just freakingly easy to rely on framework solutions, maybe bend them a bit. It is worth of it. It cuts down way more than half of codding needed. And that makes the difference. I don't blame, I love the result.
Maybe to dive in deep (a lot of investigations just to educate myself) may make my mind more clear about it but that takes time which i have just a bit if even that mostly
All created elements (if they depend on data) are coded to be able to request and receive data from server via some central communication logic. It can be one time request or register to listen updates. There is defined communication protocol which is same for frontend and server so both sides codded to follow the protocol and act accordingly.
Widget on mounted sends request. Server firues out by protocol what to do and sends payload.
As the template doesn't know anything about the protocol it is kind of manual thing per widget which is not pleasent thing to make or maintain.
This is not strategy which fit into the overall logic of build dashboard by configuring widgeds and fire. It takes custom coding on both sides and current communication which exists will be only obstacle in a way.
I can't see win her at all .
Why not utilise Node-RED's global. or flow. state stores for this?
You are correct, we have a statestore and datastore on the server-side of Dashboard 2.0 for this exact purpose. There are client-side equivalents, but their state is lost on refresh, and re-filled with whatever the known server-side state is on first load.
Each ui-template does have a statestore/datastore, but I don't expose those to the client-side currently. My reasons for doing so is that it very quickly becomes easy to abuse and memory leaks could get very out of hand, very quickly as developers would use it like a database, which isn't a reliable/efficient thing to do.
I am not entirely convinced by that argument. Could you not make the same argument about server side storage and contributed ui nodes?
The result is that responsible developers have to build more complex flows than they would otherwise.
All I need is a boolean and two short strings.
