Sashko Stubailo
Jul 10, 2017 · 1 min read

To be honest when I build apps with Apollo Client right now, I don’t write any of my own Redux stuff. I just use local state with Recompose. But that’s because almost all of the data is coming from the server, and there are not too many complex client-side interactions.

The approach is outlined here:

It doesn’t help that I’m a mantra faithful (I followed your contributions intensely), which claims no need for redux, particularly in a meteor environment.

Redux is never actually necessary — you should only use it if you find it helpful. React has state management built in, and if that approach works fine for you there is no reason to branch out to something else.

so where do you think this is heading?

We’re really excited about a potential future for Apollo where it can handle all of your app’s state, so you can query stuff like local state, the current route, local storage, and more via just GraphQL. That will be nice since your component doesn’t have to care about where data is coming from. But that might be several months or even years away, so at the moment Apollo Client handles your server-side GraphQL data and you have to keep client-side state somewhere else.

    engineer at @stripe. previously open source eng manager at @apollographql and @meteorjs, https://github.com/stubailo

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade