The common solution seems to be using redux-thunk to shoehorn all of this business logic into the action creators. I think that's an absolutely terrible idea. IMO redux-thunk muddies up the terms "dispatch" and "action creator" and essentially creates a huge noob trap where new programmers don't even know what an action creator is anymore and they use the wrong terminology for everything.
Having said that, I think the thunk pattern is a fantastic solution. The two things the business logic functions need to do their job are dispatch, and the state, and the way redux-thunk does it with dependency injection makes your business logic functions very easy to test.
If somebody can come up with a solution with the same principle but without the absolutely moronic overloading of terms that people somehow find acceptable about redux-thunk, then they'll be onto a winner.
Thanks for the input. This reflects what my problem is as a beginner with all this stuff: Where do I actually put everything? There's no universal answer of course, but this is why I (and certainly many others) feel intimidated by the JS ecosystem as a whole.
Out of curiosity, could you give me some examples of what you view as "business logic", and what troubles you're having placing that into a React+Redux app?
Thanks for the link. Business logic, to me, is: 1. Make sure that domain rules are enforced and keep data consistent. 2. For every use case, always trigger the same sequence of actions (behavior and side effects).
Imagine a fitness app where you can enter workouts and how much water you drank. You may enter only one workout per day (rule) and you cannot enter more than 1 gallon of water (rule). When you add a workout (behavior & side effects): the weather API is called and the current weather is added to the workout, the workout is stored in the DB, some calculated statistics are updated, your public "progress report card" is updated, you get a "good job!" push notification.
In my PHP OOP spaghetti approach, I might create an AddWorkoutCommand that executes() these actions by calling a bunch of other functions in other objects and trigger an event for optional listeners/actions. With Redux, not everything is in the same store (or in the store at all) and I don't even know where to start. It feels like this doesn't have anything to do with Redux, because it's partially not even state/view-related.
Maybe I'm overthinking this, but I do have a hard time finding a good tutorial that shows how to work with behavior and rules that goes beyond "add this item to the todo array".
I could picture handling that kind of thing several different ways.
First, the UI may want to prevent the user from being able to hit "Add" or something if a workout already exists for that day. The component could use a selector to determine if there's an existing workout, return the flag in `mapState`, and disable buttons or forms appropriately.
Second, the action creation logic could decide to not actually dispatch an `ADD_WORKOUT` action by inspecting the current state and only dispatching the action if allowed. (I have some relevant examples of redux-thunk use cases like this at [0]).
Third, the action could get always dispatched, but the reducer could make the decision whether to actually insert the proposed workout into state.
Regarding the side effects, this is a good use case for "sagas". Dispatch an `ADD_WORKOUT` action that triggers a saga, but is ignored by the reducers. The root saga kicks off a child saga when it sees that action. The workout saga could then decide whether it needs to actually add the workout based on state, dispatch another action that actually updates the state, make the AJAX call for weather and persist it to the server, and trigger a push notification. (You can do same thing in a thunk, it just would need explicit promise usage rather than the synchronous-looking code of a generator-based saga.)
Lastly, this isn't a direct answer to your question, but you may be interested in some of the more in-depth Redux tutorials I've collected. They're in the 'Redux Tutorials#Project-Based Tutorials" section of my links list [1]. In particular, I recommend "Building a Simple CRUD App with Redux" [2], and my own "Practical Redux" series [3].
Hopefully this gives you some ideas. I'd also invite you to come ask questions in the Reactiflux chat channels on Discord. The invite link is at https://www.reactiflux.com . Great place to hang out, learn, and discuss React + related topics.
Just to be clear, I wasn't debating the merits of thunks, I love the pattern. I was just questioning the decision to use redux middleware to implement them. Redux-thunk action creators do not return an action. It's a misnomer to call them action creators.
Having said that, I think the thunk pattern is a fantastic solution. The two things the business logic functions need to do their job are dispatch, and the state, and the way redux-thunk does it with dependency injection makes your business logic functions very easy to test.
If somebody can come up with a solution with the same principle but without the absolutely moronic overloading of terms that people somehow find acceptable about redux-thunk, then they'll be onto a winner.