It's funny, I actually prefer Redux + Thunks the "hard way" (not RTK). I find it's far easier to reason with the state, transitions and events that way. It takes a bit more cognitive overhead getting started, but the complexity doesn't grow as features do.

Redux (even with RTK) has so much boilerplate it's not worth it anymore. I'm stuck with a bunch of legacy code but slowly moving it to Context.

If you want actions and reducers just use the hooks versions for those + Context.

I find that using Context+useReducer is similar, but in the end you wind up with a lot of useContext and/or overlapping usage of different context/providers that the general single redux context is often better overall. Not to mention, that you still have to deal with the action generation and state in the scope of context, which gets even more messy with different Context usage in practice.

At least that's been my own experience. I don't fault people for going different routes, I just find that the boilerplate kind of fades into the background after it's established.

My issue is that in the worst case you end up with Redux-like constructs. If your context setup gets so complicated as to require global-like store and extraction of actions and reducers into specific files, you end up with Redux.

In the mean time, you can avoid that.

> but the complexity doesn't grow as features do.

That is exactly why I don't like it. Rather than doing as simple as possible and expanding when needed, you default to the most complex answer. The fact that it can handle anything means you don't need it for everything.