One thing about the state management recommendations: They talk about either storing the app state in component `state`, or using Redux.
An alternative I ended up going with is simply storing the app state in its own object, completely outside the React system.
This is a bit similar to using Redux, but you end up not getting lost in that tooling. You have to remember to manually send data over to the components (for example when you get API responses), since you don't get the auto-updating `setState` simply from storing app state in a component. But ultimately it lets you nicely separate the "backend" of your app with the view.
I suppose that's a viable approach, but I'm genuinely curious: if you're going to go to that route, why _not_ use Redux? Besides, the wrapper components generated by the React-Redux `connect()` function help serve that purpose of encapsulating store subscription and interaction, and keeping your real components agnostic of where the data is coming from.
The simplest reason? One less thing to learn. Once you get a feel for things you can pull in redux, but people already have a kinda hard time getting setup.
An alternative I ended up going with is simply storing the app state in its own object, completely outside the React system.
This is a bit similar to using Redux, but you end up not getting lost in that tooling. You have to remember to manually send data over to the components (for example when you get API responses), since you don't get the auto-updating `setState` simply from storing app state in a component. But ultimately it lets you nicely separate the "backend" of your app with the view.