I used an architecture based on these ideas on a big polymer project.
managing state this way helped me implement enhancements sanely, so just wanted to say thanks!
A few caveats:
you want to clone the subproperty of the state that you are modifying and then set the property back to the new, modified version when you are done, or polymer may not fire its property change events and/or update the UI properly and you will get unpredictable results.
also, as the state and UI grew we saw performance issues that were very obvious on mobile. That was because if you do a catch-all state-changed event handler with a loop as shown in this article, you will end up looping through every property of every component and updating each component, while the bit of UI that really needs to know about a certain state property can sit waiting for its update.
To solve this, I ended up making a “setState” helper in the state provider that fires a custom event named after the property changed, and the first thing state reader does on attached event is listen for events relevant to the component’s properties.
This solved the problem but I still also handle state-changed afterwards as a fail-safe.
Thanks again for this post — very helpful and simpler than redux IMO.