I'm quite surprised by the first counter example - namely about the way how the state is being stored and mutated. I'm pretty sure globals are not the standard practice, so I assume one would normally use a local variable in the main() scope.
But the point is, that I'd be also quite surprised if Fyne didn't provide a way to store the mutable state (in this case just an integer) in a more "reactive" manner (e.g. in some "reactive" wrapper which when written to - possibly even from a different go routine - would automagically update all the widgets which read from the "reactive" wrapper instance in their callback).
Does Fyne provide a better support for "live" data (i.e. "reactiveness") than using such plain "global" variables?
I'm quite surprised by the first
counterexample - namely about the way how the state is being stored and mutated. I'm pretty sure globals are not the standard practice, so I assume one would normally use a local variable in themain()scope.But the point is, that I'd be also quite surprised if Fyne didn't provide a way to store the mutable state (in this case just an integer) in a more "reactive" manner (e.g. in some "reactive" wrapper which when written to - possibly even from a different go routine - would automagically update all the widgets which read from the "reactive" wrapper instance in their callback).
Does Fyne provide a better support for "live" data (i.e. "reactiveness") than using such plain "global" variables?