I think that all the state management problems and solutions in all languages/frameworks (react, swiftui, elm etc etc) would be better implemented as a database with
changefeeds / change data capture .
The advantage compared with something like Redux is that it's more general. You don't need to implement an enum with a case for each action and then have a big dispatcher.
All your update logic would be a big switch statement on change feed from the database which would handle all the logic.
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?
I think that this solves the problem better than alternatives or the observer pattern.
Ideally the API would be something like LINQ methods in order to avoid parsing SQL.
I'm still trying to figure out if this would work.
You seem to have thought a lot about this, but I don't understand the distinction you're making and I'd appreciate help squaring this up in my mind.
In the case of Redux, you have the current state, you have actions and selectors (from a CQRS perspective, an action = a command and a selector = query), and you have reducers that apply the actions to the state then update/notify the selectors. How is this different than what you stated? Are you just suggesting the removal of actions and directly changing the state, like reactive programming, with a changefeed being generated as a side effect of manipulating the state? In that case, how do you handle situations where the update requires knowledge of the current state? Won't you need to read in the current state, apply changes, and then write back? And at some point you will want to be able to pass parameters so you can combine some input (eg. the updated user's last name in a text box) and the current state (the user's first and last name) to update another state property (the user's full name). At that point you've essentially re-implemented the concept of actions and reducers.
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!
In the Rust world, Salsa operates on similar principles: https://salsa-rs.github.io/salsa/
Personally I believe this pattern has totally solved the problem of responding to changes in state, and its use-cases are just beginning to be explored