Is it bad form to just fetch data via GraphQL and put it in Redux (or other store)?
I'd like to buy in, but I'd like to keep my data fetching separate from my view layer if possible.
Is it bad form to just fetch data via GraphQL and put it in Redux (or other store)?
I'd like to buy in, but I'd like to keep my data fetching separate from my view layer if possible.
Honestly, it was a pain, but it's because we abused Redux.
We progressed by doing the HOC and bypassing Redux but it still was a pain, because HOC.
We're now at a stage where we updated Apollo versions, and started converting to the Query components. It feels and work a lot better.
When we started, we thought the same thing -- keeping data fetching separate from the view layer if possible. We realised that it didn't make that much sense. Keeping everything in React components is a lot more maintainable and easier to comprehend.
Also the subscription via websocket story there is really sweet, you basically get real-time update for nothing ;)
In short, just as John stated, it’s a huge boost of productivity on both front and backend, we verified it ruthlessly and love it.
You can use the new render prop API instead of the HOC API if you don't like wrapping.
The data fetching itself is separate from the view layer—it's all done by Apollo. From a maintenance perspective, listing data needs is great to have in the view layer, colocated with the components that use them.
You can manually fetch data via GraphQL and put in Redux, but there are a ton of benefits to having a library like Apollo manage the store for you. Automatic normalization, querying from either store or server (or both), optimistic mutation updates, etc.