This will require a little re-think of our underlying architecture, as this should just be working out of the box, but the events flow doesn't allow for it currently.

Forum Discussion: https://discourse.nodered.org/t/how-to-retain-the-state-of-a-button-on-and-off-between-page-updates-and-different-browsers/86404/8?u=joepavitt

Also https://discourse.nodered.org/t/dashboard-2-changes-in-one-viewer-not-reflected-in-another/85949/5

Hi,
is there any progress on this issue?

Kind Regards

Sorry @uschmelmer - no updates on this currently

So we use widget-change as an event to register a "change: of state. This event is found in:

1. Button Group
2. Dropdown
3. Number Input
4. Radio Group
5. Slider
6. Switch
7. Text Input

I can make them all synchronise, but some of them feel odd to synchronise, particularly 7, and maybe even 2?

It's worth noting, we can disable this functionality at any time using the "Client Data" tab, which sets up each client/'browser as a unique session for a given widget type.

@colinl would really value your opinion here too?

I think they should all synchronise.
Text input is conceptually the same as number input, it just happens that one is entering text rather than a number.
Similarly a dropdown is just a text or number input with a limited set of values.

Watch out for the switch node when in 'show state of input' mode. It would be easy to break that I imagine.

Can you describe the use case for not wanting sync?

Can you describe the use case for not wanting sync?

In all of your internal Dashboards at FF, I would say we'd favour no syncing, but in the HMI use case on a Factory Floor, I can see the sync being favourable.

I built a first iteration today, ans it works very well, and utilises the existing "Client Data" tab, where you can check on/off syncing already, to decide whether to sync to different sessions or not.