Some questions about state mirroring in Flexdash

[BartButenaers]

Hi folks,

It is a real shame, but I still didn't find time to do UI node development in Flexdash. But should get started with it soon...

@tve has written a nice article about state mirroring in Flexdash. This is very important for me, because I can't count anymore the number of development issues I had due to message resending in the old AngularJs dashboard. So if Flexdash is able to reduce the headache for UI node developers, that would be very welcome.

I have a few questions about the article:

1. There is an example provided of how a state cache looks like in Flexdash:

   

   Although this is internal Flexdash kitchen, it always helps me to develop if I know how stuff works.

   Does this mean that Flexdash maintains two states:

   • The current state
   • The new state

   And that it calculates the delta as soon as the state is updated via the API, so that the delta can be send to the frontend. And then the old state is immediately automatically removed? Or does it keep - for some reason - multiple states?

2. The API currently already has some nice functions to deal with arrays, since that is being used a lot of course in Node-RED messages. But I find one example a bit cryptic to read:

   

   That is for me code where I need to add some comments, because afterwards I have forgotten how it works...

   I know that you can't add all array handling functions to your API, but wouldn't it be more simple if you provided a setAtIndex(name, value) or a set(name, value, index)? That kind of "convenience functions" in the API would really support my old brain

3. Sorry if I have overlooked it, but how do user interactions in your frontend widget update the state in the cache? Do we need to wire the output messages to the input again, to update the state? But that is perhaps a bit of traffic overhead, because you send the same state to the frontend which is already at the frontend. On the other hand if you N clients open, they of course all need to have a state update in their frontend. Please illuminate me...

4. Are there any other functions you had planned to add to the API in the future? Because it could be that you had other things in mind, but had no time for it. If so, it would be really usefull if there would be a short API description in the documentation. Where we can easily find the functions and their parameters/return value. So that you can add there comments like "planned", "to be discussed" or whatever information that can help us while developing. And yes I know that it currently will be a small list, but you never know somebody can convince you to add some more functions afterwards

Thanks for all the time you spend on - beside your developments - to teach our community!!!

Bart

[tve]

@BartButenaers

It is a real shame, but I still didn't find time to do UI node development in Flexdash. But should get started with it soon...

I will refrain from answering until you roll up your sleeves and get started

[tve]

@BartButenaers

And that it calculates the delta as soon as the state is updated via the API, so that the delta can be send to the frontend. And then the old state is immediately automatically removed? Or does it keep - for some reason - multiple states?

There's only one copy. The JSON snippet was intended to illustrate having two widgets, one that was just changed and another unchanged.

The change detection is also only based on the operations performed, it's not a diff. I should rephrase some of the text. So if you set 'payload' to the value 2 repeatedly then that gets sent repeatedly.

I believe I could now pull Vue's reflection into Node-RED to make this more powerful, but I don't think it's worth the hassle.

@BartButenaers

I know that you can't add all array handling functions to your API, but wouldn't it be more simple if you provided a setAtIndex(name, value) or a set(name, value, index)? That kind of "convenience functions" in the API would really support my old brain

You may want to write those helpers
The set method accepts a path, so you could also pass payload/series2/max[123] and update that value... So far I haven't used much of that outside of the FD internals, we'll see whether complex use-cases emerge. (And in those cases a custom helper is probably the best route...)

@BartButenaers

Do we need to wire the output messages to the input again, to update the state?

Yes & no. Interactions primarily send messages to Node-RED, so yes, they need to be looped back. There is a checkbox in the general pane of the core widgets to make that painless.

@BartButenaers

you send the same state to the frontend which is already at the frontend

You're assuming that the dashboard where the input happened doesn't need to receive the loopback. The core widgets do need it. But if this becomes an issue we can look into providing an option to send to all-but-one...

@BartButenaers

Are there any other functions you had planned to add to the API in the future?

No plans, and yes, I'd like to add a description of the functions to the docs. Right now they're in node-red-flexdash/plugin/widget-api.js at main · flexdash/node-red-flexdash · GitHub but it's probably a bit confusing because some of the functions there have to do with widget initialization and destruction and not with updating props...

[BartButenaers]

@tve

So if you set 'payload' to the value 2 repeatedly then that gets sent repeatedly.

Ah when the value is unchanged, you send it again to the frontend? Does that have any advantages?

@tve

You may want to write those helpers

Ok deal! When I start with it and I need something, then I will create a pull request.
Was not sure whether you were prepared to expand your API. Don't say your API should be cluttered with a massive amount of methods, but some convenience methods makes it easy to use it without too much of workarounds.