| I've always been a huge fan of Redux, but lately I've become even more enthusiastic about Apollo Client 2.0 and the apollo-link-state project: https://github.com/apollographql/apollo-link-state What this will let you do is basically extend your server-side GraphQL API with a set of local resolvers for queries and mutations, and let you query and mutate both your server-side and client-side state using a single consistent API (GraphQL, with client-side fields decorated with a @client directive), backed by a (mostly) automatically normalized local state cache (by default apollo-cache-inmemory, but customizable, so you can even implement a Redux based cache if you'd like more control). A lot of the complexity in Redux today stems from the need to reconcile client-side state with server-side state, usually fetched through some kind of async actions paradigm like Thunks+Promises, Saga, Observables, etc, to be then manually merged into the local state after being transformed into a normalized form. I personally think one of the biggest problems with the design of Redux is that the architecture derives most of its benefits from having a normalized state tree, but it also makes it all too easy for developers to store non-normalized data in the state tree. Although admittedly an architecture that does enforce a normalized state tree would be an order of magnitude more difficult to learn and work with in the wild-west of RESTful APIs that used to be the de-facto norm back in the days when it was designed (and it still is, though that may be slowly changing with the rapid adoption of GraphQL), where most server-side data you receive isn't easily normalizable to begin with. A good GraphQL client like Apollo can already abstract away much of the complexity involved with async server requests through its Higher-Order Component-based API, which simply provides data to the wrapped component as props, so it doesn't need to know how to fetch that data. More importantly though, Apollo also ensures that all the server-side state it maintains in its cache is stored in a normalized manner, and GraphQL makes this fairly easy. Apollo-link-state goes a step further and allows you to use the same abstractions for managing client-only state, and store it in a normalized form alongside your server-side state, to allow for a much more consistent and comprehensive state management API. With all that said, apollo-link-state is still really young and I've only played around with it briefly in toy projects, so there's no guarantee it could scale as well to large teams as Redux has. I do still personally find it to be one of the most promising alternatives out there though. Lastly, Relay Modern also supposedly has something called Client Schema Extensions, which I assume is similar to apollo-link-state, but wasn't able to find any documentation on it outside of a brief mention in its release notes: https://facebook.github.io/relay/docs/new-in-relay-modern.ht... |