None of my projects want to be SPAs

First question (show user data in nav bar, user details page, and "comment thread"):

User profile page is obviously showing full user details, so you're going to want to have a separate endpoint for "getUserDetailsByUserId(int userId)" or however you want to name it.

What data are you showing in your nav bar? Is this just a user-avatar image link/button? You would rarely want to display anything other than an avatar and/or username in a navigation bar. You could maybe talk about a navigation drawer instead, where you have more simple details like maybe email address and phone number or something.

What about the "comment thread"? Are you showing anything more than an avatar and/or username? This sounds like the same use-case as the nav bar... how would the display differ here?

If you have use-cases for anything more than your basic "user avatar" and "full user profile," (and maaaybe "user basic info," for a "nav drawer" or something, although those are being phased out of most current design standards) then I would seriously urge you to re-think your app design. That polish of showing the user info in a slightly different slice on some specific page is almost never going to pay off for your company, imo.

Anyways, if you want to be naive about all of this, you just save the userId (and token or whatever, but that should be in your http middleware) after a new login session, and then you request separate "getUserNavBarInfo(userId)", "getUserDetails(userId)", and "getUserCommentInfo(userId)" and load the results of those into your UI views on-demand. If you need to progressively tune/cache your API, you do this separately based on usage stats for each of these 3 use-cases, you don't start with directly caching "Users" and adding the business logic client-side to translate into the 3 use-cases.

If you want to do a more thorough dependency-injection "user component," then this might vary depending on your DI framework, but the high-level idea would always just be to create a user module with all the info needed for a given user, wire it up to reload the module in your DI graph on new login and on-success of any request to update user info. You could have both your "login" and "update user" endpoints both return the full set of data needed for the "user module" on success. Then you need to set up your DI injection component scoping so that your user info injection component is dumped on user logout and settings change, and is recreated to do it's injections with the new/updated user module each time. A singleton DI "user component" that you must choose to inject into any UI component that wants to show user information seems much more constrained in complexity to me than just having the ability to arbitrarily pull out various bits of user info from a global redux state, at any place in your app.

Second question (single source of truth, increases or decreases complexity?):

I think this question is orthogonal to the capabilities Redux (and similar) provides. Redux has nothing to do with outright increases or decreases in app complexity, it is simply a tool that enables various (opinionated) architecture patterns. If you have a separate, domain-specific, well-defined event+data architecture that you are sticking to very strictly to keep a handle on complexity, then Redux can (imo) reduce boilerplate and allow very elegant interactions between various data/biz logic/UI components of your application, all without any "tight coupling". It's really just a message-bus pattern at some level. This sort of thing has been around longer than the concept of software itself, there are hardware components literally called "buses" that basically do the exact same thing (ship events and data around to various interested parties without requiring a direct circuit connection). The danger is that it opens up a TON of pathways to insane complexity and totally unintuitive event & data flows, because it kind of allows you to arbitrarily add "side effects" to basically anything in your application. VERY easy to foot-gun yourself here if you start getting lazy and just wiring up random shit instead of following strict event/data patterns and keeping the "feature code" as simple as possible (e.g. with a strict facade for writing new pages).

This might rustle some feathers on here, but I wish people would think of React/Redux sort of as "framework primitives" that are SUPER useful for constructing your own domain-specific client-app frameworks, but somewhat dangerous to open up directly to front-line product code written by junior devs. I would much rather see a few senior devs use React/Redux to construct a tightly-defined domain framework that exposes a simple facade to junior devs to construct new pages/routes/behaviors in your FE application. I think using these tools like this would greatly reduce the dreaded "React learning curve" of 3-4 months that everyone talks about. That could be done over time if you put in the work up front to build an internal facade pattern around your core React/Redux app architecture. Then junior devs could choose to dig into things behind the scenes as they go, instead of being forced to front-load the entire React/Redux knowledge stack up front right when they walk in the door.

And then you're right back to any component that uses User being tightly coupled to the structure of the User, without any of the syntactic cues that allow you and your static tooling to connect the two.

> except those solutions are sprinkled into your UI components in a way that makes them full of mutable state that is impossible to test and a constant source of bugs.

That's not the case:

1. There's nothing preventing you from treating components as a pure function of their props.

2. At the top level, it's necessary to have some mutable state, but I'm not sure where you get the idea that this isn't testable. Redux doesn't remove mutable state: all redux is doing is a big complicated version of newState = pureFunction(oldState) which is perfectly possible to do using Vanilla JS functions.

It was a mistake because we needed to move fast and figure out if we had something or not. A simple CRUD website (say Ruby on Rails, Elixir/Phoenix, or even straight up Node/Express) would have been faster to build and iterate on.

There was one section of it that would benefit from being able to work while offline, so that could perhaps have been built as a small SPA. But the rest, that was in hindsight a mistake.