Yeah I’d read that you do that. Similar to redux in some ways, having a single, big store and managing everything from there. What redux does is make it more formalised. But like adamski, prefer mobx for smaller projects.
It revolves around ‘observable’ variables. You mark a variable as observable (could be an array or map) and mobx will begin tracking usages of it globally, and builds up a graph of what relies on what, sending triggers down the tree if something changes.
Another key method is autorun. Code within an autorun will be called anytime that an observed variable that it uses changes. In a Juce context, you would wrap this around a Components paint function, so that for example if it’s using an observed variable ‘text’, it will automatically repaint when ‘text’ changes. I guess it’s similar to listening to changes on a ValueTree, but when it becomes much more useful is when the chain of reactions is longer than one. Like, when text changes, you need to go to a server to search, return those results to 3 places, transform it and update 5 things in the UI.
Another usage of autorun could be debounced autosaving.
To do this in Juce we would need a TrackingHandler class to manage building the dependency graph and tracking changes, and some additions to Value to tie it to the TrackingHandler. Then methods on the trackingHandler for doing autorun.
There’s other things too, like transactions that wait for a block of code to complete before computing all reactions at once.
Maybe a more advanced state management system in Juce isn’t so necessary, everyone likes to do it their own way. I guess mostly this me a bit miffed at my own badly written code that relies too much on ValueListeners and then having to deal with the resulting async screw-ups. These are just ideas from the web world. I think they definitely do some things right.