4 ms·
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
by ChicagoBoy11 9y ago
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 9y ago> 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 9y agoThere 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 9y agoAnother 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