add "claims_version" event sent at each claims change.

[KipK]

throw claims_version event at each claim change , incrementing from 0 to 254

[KipK]

I don't remember where we've talked about this alrady. Also, I'm starting to need that for other cases in the UI.

[jeremypoulter]

Looks good, will test

[KipK]

I see a problem with current implementation.
As Shaper is using claims and modulate quiet often, this throws a lot of new claims_version, deserving the goal of limiting poll traffic.
there's no need of getting those shaper/divert claims updates

We need to find a better logic for the claims_version

[jeremypoulter]

I guess there are arguments for eventing only on additions/deletions of claims and skipping updates of existing claims. In all honesty do what best suits the v2 UI use case and we can fix any additional use cases if/when they come up. Really we need to update to a proper pub/sub protocol on the websocket I think.

[KipK]

I guess there are arguments for eventing only on additions/deletions of claims and skipping updates of existing claims. In all honesty do what best suits the v2 UI use case and we can fix any additional use cases if/when they come up. Really we need to update to a proper pub/sub protocol on the websocket I think.

Extending websocket to a proper pub/sub protocol would simplify a lot the client logics.
This will need first to have a proper stored data implementation on ESP32 to handle event on data change only.

Btw, the Svelte "store" engine I use in UI 2 is already pub/sub based on client side.
All the data are coming in global stores and dispatched to subscribed components, a bit like Redux without the headaches

Keeping the same flux to the client/server implementation would cleanup a lot of code.

[KipK]

So for now it updates the claims_version only for change coming from other clients than divert & shaper.

[KipK]

I've changed to what you said, only increment when there's a state field in the key

[KipK]

lucky you hadn't merged it yet, it introduced the bug I was talking about in the other PR.
It's fixed now

[jeremypoulter]

@KipK Please could you take a look at the conflict?

[KipK]

mhh not sure of what happened here