Another commenter mentioned it, but I'm going to +1 using Redux [0] as well. If you need to pick up a framework, Redux is a great choice to consider, it's tiny and very simple. It pushes you towards keeping a lot of your business logic as pure JS, so testing your code tends to be really easy (and it means your code is re-usable, it's not tied super tightly to X or Y framework!). If you use it with React it's also a joy to test.

Something that Redux doesn't solve is data fetching, caching, and mutations. If you have a reasonably sized application, you'll end up having to implement a lot of logic surrounding data fetching and caching by yourself. The suggested solution is to store your resources normalized, indexed by id, and create selectors to get the data in the shape you want. This works out alright, but it's tedious and during your first few iterations on it you'll probably find yourself with a lot of boilerplate code.

Facebook released Relay [1], which gives you the solution for data fetching and caching. If you give it a try, you'll be amazed by how much mental overhead simply disappears. You want data? You get it, that's it! But then your new problem is that you need a GraphQL server, and since it's a new technology that's not very mature (outside of Facebook at least), it means you'll have to do a reasonable amount of exploring. (I should really clarify that this is in no way the fault of the Facebook teams that put out Relay and GraphQL, both tools are amazing! It's simply that the ecosystems needs time to evolve and adapt.)

I'd say that in one or two years from now a formidable amount of frontend app will be using some variation on Relay and GraphQL.

[0] https://github.com/rackt/redux

[1] https://facebook.github.io/relay/