
Reducing Our Redux Code with React Apollo - djmashko2
https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a?source=linkShare-803918030a60-1497032202
======
ChicagoBoy11
What I was hoping the article would go into a little bit more depth in is how
they wrapped their heads around the "Redux" pattern of organizing your
application to this much more component-centric declarative style.

With Redux, you are encouraged to do a lot of the app heavy-lifting in action
creators. But with apollo-react, all of that data-fetching is happening on the
component itself and is driven by the components own needs. The actions
dispatched by apollo-react client are pretty generic, and I've found it
difficult to use them meaningfully in my own reducers.

In other words, I can perfectly see how the author was able to drastically
reduce LOCs, complexity in their app, etc. I still cannot fully see how that
architecture is compatible to current Redux best-principles (which to have
served me quite well so far).

~~~
namuol
> With Redux, you are encouraged to do a lot of the app heavy-lifting in
> action creators.

I've seen/learned quite the opposite: do as much of the heavy lifting in your
_reducers_ as possible.

Lighter actions (that more closely reflect the _cause_ of a change in your app
-- not the change itself) tend to lead to less-tangled code.

~~~
davidjnelson
There seems to be some big downsides to intermingling side effects in action
creators vs immutable state changes in reducers. Reducer logic would then
require complex mocks. Reasoning about side effects and immutable state
changes separately feels natural to me. Would love to hear how putting the
side effects in the same functions used for immutable state changes makes code
_less_ tangled.

~~~
actsasbuffoon
Another possibility is using sagas for handling side-effects. I've been happy
with that approach.

[https://github.com/redux-saga/redux-saga](https://github.com/redux-
saga/redux-saga)

------
lucfranken
While interesting be aware of those quotes from the article:

About offline:

> Local storage action creators & epics (~1000 LOC). This is a bit unfair to
> count in the total because offline support for our project is postponed, but
> it’s achievable if we want to add it back in by customizing the Apollo
> fetchPolicy & exposing the reducer to redux-persist.

About mutations (insert/update/delete statements):

> While our server is currently “read only,” we may need to introduce
> mutations in the future to save a user’s favorite team.

When considering GraphQL test those as well because the "loading data" part is
very cool and easy to grasp. It gives instant results, really cool.

Updating data is not as easy as that and not as mature yet. There is an
ongoing process of finding how to update the local data store.

See for example comments in the documentation:
[http://dev.apollodata.com/react/cache-
updates.html#updateQue...](http://dev.apollodata.com/react/cache-
updates.html#updateQueries)

So while it's a great tool understand your app's processes before diving in
completely.

