> The fundamental problem of state management is as follows, if a leaf view changes some data, how does some view higher in the hierarchy learn about this? At

> The fundamental problem of state management is as follows, if a leaf view changes some data, how does some view higher in the hierarchy learn about this? At the end of the day, if you have a relational model and you want to allow subscriptions arbitrarily on the object graph, something somewhere will have to traverse the tree of the object's parents and apply a notification to them, right? Or you will have to only allow replacing object changes/subscriptions at a flat level, which is a document-based model rather than relational. In that case, you can filter the notification stream as an optimization for the clients, but the entire document would require replacement on every update. You can do an additional optimization and allow patches of the object, and use diffing to not notify if a specific property was unchanged after the state update, but these are all implementation details. I don't think this is a fundamental problem of state management, more-so a restriction of state management when dealing with state expressed as relational objects, and one of the reasons document databases are easier to reason about. Bringing this back around to state management frameworks like Redux, each Redux store is essentially a single document and selectors are filtered notifiers of changes. This project sounds interesting - you should make a blog post about your prototype database with some more details, I would love to read it and see some of the code!