THe problem I've found with this approach is that it gets very messy very fast. It's hard to track down bugs to their source.

One of my favorite aspects of Redux is how easy it is to follow the flow of data. Whatever you do, you start at a dom element, look at what action creator it calls, and check out the changes in the reducer.

Yes, agree it is a bit messy now but still manageable as i wanna delay using Redux / Mobx as long as possible.

I've also delayed introducing Redux to a project before, and it was a mistake. After a few weeks of convincing, I got time to add Redux to a project, and it's immensely difficult because of how much needs to be restructured. It's better to just start with it if you're going to end up creating something large enough or complicated enough to warrant it.

In theory, if you've been following a "container component"-type approach, you _should_ be able to start replacing those hand-written containers with Redux-connected ones.

What kinds of issues and restructuring problems did you experience?

No, that's not "wrong". But, it does sound like the kind of case where Redux might be useful.

Yeah, that's why i suspect it might be a a good use case for Redux but not very sure. Hopefully something better (Mobx, etc.) comes along when i decide to implement a state manager.

Well your site works, doesn't it? Can't do something wrong if your site is all right.

Compared to my JQuery days, it is a big improvement in terms of maintainability now. No complaints!