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).
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.
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.
5 comments
[ 2.9 ms ] story [ 23.3 ms ] threadWith 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).
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.
https://github.com/redux-saga/redux-saga
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...
So while it's a great tool understand your app's processes before diving in completely.