I'm a consultant and in my experience this misconception is by far the most common source of problems in redux projects. Redux is a very small and simple thing so you have to build a framework around it. Even redux-thunk isn't enough - that's only 5 lines of code.
I wouldn't recommend react/redux for public facing sites if there's no experienced, pure frontend team. A more batteries-included kind of framework would be better. There's a lot of thinking to do and hardcore levels of scaffolding to maintain before writing anything useful and maintainable with redux. But it can absolutely lead to maintainable applications.
Also, I've never seen any homegrown "vanilla" frameworks or data stores work well as complexity increases. It usually ends up as spaghetti, especially with a growing team + growing business demands. Or best case a poor re-invention of the wheel. There must be brilliant counter examples but they're probably rare, I may never have the pleasure of working with one.
FWIW, we've got a new Redux Starter kit package that tries to be a bit more "batteries included". It includes utilities that help simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically. It also includes `redux-thunk` built in, as well as some middleware that check for things like mutations.
Please try it out and let us know what you think!
I understand why folks have opted to create higher-level frameworks around Redux like Rematch, and it's not "wrong" that they've done so. But, looking at Rematch code, you can't really tell that it's actually Redux underneath.
With RSK, I've aimed for an intermediate level - decreasing the amount of things you have to write by hand and the literal number of keystrokes you have to type, but preserving the idea of "dispatching actions" and using reducers.
Glad to hear that you think it looks good! If you've got any additional feedback or suggestions, please let me know.
I'd say that the only times I've seen Redux work effectively at all is when the project was small enough that the complexity remained manageable.
> > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc.
> That's the problem: react and redux are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose.
I don't need a way to manage side-effects, if I don't use Redux...
I'll admit I haven't used Redux-Saga, but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem.
> We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic.
Again, this is not unique to Redux. It's perfectly possible to have your business logic completely separate from the UI layer without Redux. In fact, my experience is that Redux tends to cause devs to mix UI logic into business logic (and any sufficiently complex UI will have its own state and logic separate from the business logic).