reflux / refluxjs

A simple library for uni-directional dataflow application architecture with React extensions inspired by Flux
BSD 3-Clause "New" or "Revised" License
5.36k stars 330 forks source link

Are reducers supposed to be pure? #519

Closed made-by-chris closed 7 years ago

made-by-chris commented 7 years ago

I'm wondering where to place my API calls within my reflux application. Would within the reducers be appropriate or are they supposed to be pure as with the general flux pattern? It seems this would be the quickest solution. I was thinking that perhaps wrapping 'view components' in 'container components' is better design. The container components could then handle the API calls.

BryanGrezeszak commented 7 years ago

I'm not 100% sure I understand the question (because Reflux doesn't use reducers in the same sense that Redux does, so something might be getting lost in terminology translation).

So by reducers I assume you mean the methods within stores that are catching and reacting to action calls (which are the closest equivalent to Redux reducers, though they're never quite "pure" because they work off calling setState, not off returning values like Redux) and I'm assuming that by API call you mean the calling of an action?

So the basic question is, can you call actions from the stores during an update that's happening from some other action? Is that about right?

From a technical perspective, Reflux is not opinionated on that. My recommendation is that if you're going to do so, then at least put it at the very end, so that the current function's changes are all complete before the next action begins its work. That'll make it more readable what's going on, and less error prone.

However, there're reasons Redux recommends the pattern that it does...and they're not bad reasons.

If action A always ends up calling action B, then it's usually smarter and cleaner to just wrap up all the things that A and B do together so that each action is its own modular set of changes to state...easier to read, easier to map the flow of what actions do what, etc.

But I also recognize that there might be times when chains of actions need to happen, and you might need to start it in different places in the chain...and DRY concepts would then mean that A calling B calling C calling D with the ability to start the chain at any point in the middle makes more sense (so that you're not writing ABCD, BCD, CD, and D all as separate concepts with a bunch of repetitious code).

But that should be the "expert level" concept of flux type usage :) As a generalized rule, pure is better.

made-by-chris commented 7 years ago

Sorry to clarify by API calls, i meant AJAX requests.

BryanGrezeszak commented 7 years ago

Still, I assume you're doing your AJAX requests as part of async action calls? The concept is the same, assuming I'm on base about what you're asking.

made-by-chris commented 7 years ago

they are callback-based AJAX requests within the 'reducer' functions in the store. Thanks for your help