Make it easy to use Apollo with Redux directly

[abhiaiyer91]

How does this play well with existing React Redux setups?
What was the design decision here?

Should you be more transparent about whats in this via standalone react redux. If i add this, do I have to remove my current module?

[stubailo]

Yeah, I should write a post about this with a diagram.

Basically, Apollo lives in Redux alongside your normal Redux data. It could be a separate store, but there are a lot of advantages to having exactly one store if you're using Redux in other parts of your app. Since the store format is normalized and relatively complex, most people won't want to interact with the store directly using mapStateToProps, so we decided to add an abstraction on top of it which just gives you the thing you need - the ability to make queries and get the results.

Rather than shipping some helper functions that you can use inside mapStateToProps in the normal Redux connect, it seemed more natural to provide an additional, GraphQL-optimized API. So what we have is an Apollo Provider which wraps the regular Redux Provider but adds a reference to apollo, and a connect which wraps regular Redux connect but adds a few more options.

You can easily keep using the normal Redux connect anywhere you don't need GraphQL data.

---

So if you're already using Redux, the steps to add Apollo to your app are:

1. Add the Apollo reducer
2. Add the Apollo middleware
3. Switch out Redux Provider for Apollo Provider, and pass in client
4. Just switch to the Apollo connect where you need to. All of your existing Redux stuff will work unchanged!

[abhiaiyer91]

Don't you think this is the same slippery slope Meteor did from the very beginning? Building out some custom library that you then have responsibility to maintain and therefore increase the potential surface area of issues?

I personally think what would have been more appropriate would have been to provide helper functions so people have more control of their own Futures.

[abhiaiyer91]

Can you also ship those helpers so people can use mapStateToProps themselves?

[stubailo]

I think this library is far far smaller than the scope of Meteor so I don't think it's a huge problem, but it shouldn't be too hard to export those helpers!

[jbaxleyiii]

@abhiaiyer91 what helpers are you taking about? I'm happy to export anything you would like!

We were able to switch out our existing redux react app using the steps @stubailo mentioned. Can you outline how you would rather use Apollo with your setup?

[stubailo]

OK so what about a design like this:

1. We export the Apollo reducer
2. We export the Apollo action creators (init query, stop query, etc)
3. We export something like readQueryFromStore

These all exist inside the client anyway, so it's not a lot of work!

Then we just document how to use these. Personally I think most people will prefer a nice container like the one we're working on here, but why not have more freedom!

[jbaxleyiii]

Let's export the action types too, that's common for redux modules to do

[jbaxleyiii]

(state) => ({ 
  nameOfProp: readQueryFromStore(QueryOptions, state.Apollo, client),
})

Something like this?

[stubailo]

Yeah, we need the client because we have some config we need to share between the reducers and the function that reads out of the store.

Also, that needs to take in a queryId maybe?

[jbaxleyiii]

@stubailo I was thinking we could write that sync read method and use it with a normal query. This helper wouldnt actually call the query, only read whats in the store right? Otherwise that's a redux antipattern

[jbaxleyiii]

Fwiw, this feels like it would be 100% changes to the apollo-client, not this library. This one choose the wrapping of redux route

[stubailo]

This helper wouldnt actually call the query, only read whats in the store right? Otherwise that's a redux antipattern

Oh, I guess I was thinking that passing in queryId rather than QueryOptions would be better.

Fwiw, this feels like it would be 100% changes to the apollo-client, not this library.

Agreed.

[stubailo]

Going to close it here - thanks for the suggestion, @abhiaiyer91! I think we'll keep this wrapper though if at least to use it internally. Going to start rewriting parts of Galaxy with this soon.

[abhiaiyer91]

Thanks for the quick replies on this guys! By all means I think the wrapper is great for people ! Don't get me wrong, but for devs or teams with more preference and need for fine grained control we much rather have the building blocks and we'll put together the interface ourselves! Thanks again!

[suhail-ansari-apconic]

Please keep the wrapper. It is much easier for people like us who are starting on Apollo to test things out fast.

[chris-guidry]

@stubailo, did you have a chance to write a post regarding interacting with the Apollo Redux store using the Apollo connect wrapper? I'd really appreciate seeing an example of how to read/write to the store.

[stubailo]

@chris-guidry can you open a new issue please and add a description of what you're trying to accomplish?

[baerrach]

@chris-guidry Is Integrating with Redux the post you are looking for?

[chris-guidry]

@baerrach, nope, but thanks. I am not currently using Redux so I don't have an existing Redux store to integrate with, but there are a few instances where I need to save data for a few different components to use and would like to explore using the Apollo Redux store. Anyway, I will post a new issue describing that need more specifically.