I've built a couple of applications with React. I've spent the last 6 weeks on a contract where I'm building a React based Google maps widget. I'm getting to the point where I'd like to break up a large "smart" component into smaller, more maintainable smart components. So, I'm looking for a state management library to help. I've walked through some training courses at Udemy on Redux and I've built a small personal project with it. I don't want to beat a dead horse, but the boilerplate is really off putting. I feel like I'm being exposed to the internals of a framework that's missing some higher level API abstraction that makes state management less onerous. I think the Rematch library presents a nicer surface API: https://github.com/rematch/rematch. But, I'm hesitant to use it over Redux for client work because I want to make sure I develop something that's easy to hand off, and Redux is sort of king right now. I just spent some time with the apollo-link-state docs. I know it's young, but this does not look like an improvement over the Redux state management API. Hopefully if this is to be the Redux successor, the API will improve with maturity. I kind of wish Ember Data was usable as a standalone library. It looks like such a nice, easy to use wrapper around state and data management.
MobX might be a good option for you. But to your point about Redux's boiler plate, it may be off putting and somewhat onerous, but like brushing your teeth...putting up with Redux's boilerplate will pay dividends over the long run. I think that Redux changes your program's architecture in a powerful way in that your UI becomes fully driven by deterministic state changes. There's no way around this but to explicitly declare all the possible actions your users and processes can take and expressing the mutations in state those actions should result in through reducers. Trust me that for any non-trivial and long-lived application this pays dividends in the long run. Simpler state models with less boilerplate tend to be great for small-medium projects that are short-lived, but do not evolve well.
Thanks for the reply. MobX does look interesting. I recently watched Preethi Kasireddy's presentation comparing MobX and Redux (https://www.youtube.com/watch?v=76FRrbY18Bs), which I'd recommend watching to anyone in my shoes. A couple of things give me pause about MobX. One, it doesn't quite have the inertia or industry buy-in that Redux has. It's popular, but in terms of GitHub stars, it's less than half as popular as Redux. Alone this isn't super meaningful, but if you look at the contributors page for MobX, it seems like it's predominantly the work of one person. Again, not super meaningful on it's own, but Redux seems to have the benefit of a larger group of core contributors working on it and larger community support. Just circumstantial evidence, but I feel like it's a safer bet for client work on this front. There's value in following the well worn path. The other thing that gives me pause about MobX is this opinion I've heard a few times and you've just re-iterated, which is that MobX is easier to work with and possibly better for smaller projects, but Redux scales better. I'll concede, it's possible I need to quit whining about the funkiness of Redux and live with it for awhile. It might grow on me. :)
You might want to fish up the MobX users list in one of its github issues. The users list is huge, and includes rather large projects such as Battlefield 1's UI, CoinBase and I think the new MS Outlook to name just a few.
Just wanted to say thank you for mentioning rematch, it's exactly what I've been looking for.
I've built a couple of apps with redux and always wished it was closer to clojurescript's reframe in terms of minimal boilerplate. Rematch does exactly what I need.
My main smart component is several hundred lines long at this point. The methods in the component are largely event handlers used to manipulate the component's state object. The methods are passed down into the hierarchy of "dumb" components via props, and are called when actions occur in those components (e.g. onClick some element). The methods are conceptually group-able into 4 distinct areas of data manipulation. However, the catch is that many of the event handler methods need to modify other pieces of the state object too. So, for example, I have a number of methods related to polygon state management. I'd like to move these into a <Polygons /> smart component, but when updating a polygon, I also, in some cases, need to update data for another potentially extractable smart component <Toolbar />. A state management library would allow me to move/group data management logic into smart components that would also still have access to other parts of the state tree.
