4 ms·
I personally dislike some things about Apollo & prefer Redux+graphQL+RxJS combo, and can't wait to see what happens w/ React Suspense The problem with Apollo t
by joshribakoff 9y ago
I personally dislike some things about Apollo & prefer Redux+graphQL+RxJS combo, and can't wait to see what happens w/ React Suspense
The problem with Apollo that I cannot get over is it couples data fetching to components. The whole reason Redux is popular is it decouples UI actions from data fetching. It decouples asynchronous logic from state mutations. Apollo intentionally couples that logic.
With redux, I can dispatch an action anywhere in my app to trigger a data fetch. That data fetch itself could be a graphQL query.
With apollo, I have to mount a component to trigger a data fetch. The workaround to pre-fetch data is to render a "dummy" component, causing it to pre-populate the cache.
Another issue, Apollo batching seems to be "all or nothing". Any components mounting in the same event tick get batched into 1 query. This is a problem when one query is in the critical UI path & is fast, but Apollo has batched it together with a slow query that is not critical. Think about mounting an <Article> with some <Comments> below it, but you don't want to wait on rendering <Article> just because <Comments> is slow. Now you have your fast UI components blocked from rendering because you're waiting on this batched request.
With Redux I would get around the batching problem with redux-observable middleware. I could write an epic that looks for actions, buffers these, issues multiple graphQL queries (while giving me control over how to batch them, if at all), and deal with responses in real-time as they arrive.
With Apollo v2, they totally ditched Redux. There is no escape hatches in Apollo to deal with the problems that Redux solves. That being said, Apollo cuts out tons of boilerplate & its a great library, so give it a try & decide yourself. Personally I think co-locating data requirements with components is a wonderful concept but the current implementation of graphQL clients is quite stovepipe.
Also the landscape is about to shift again due to React suspense. You would throw a promise in your render() method, and React will block rendering of the component tree within a <Placeholder />, conceptually similar to error boundaries. There is rumor of a Redux integration as well.