(Read this if you have some questions about this repo) Some questions

[msageryd]

Interesting library. I'd like to try it out, but I have some questions.

Q1. How do I execute an effect?

• Via an ordinary dispatch?

Q2. It seems that the actions included in effects are not dispatched to the store.

• If true: I'll end up with a bunch of actions which should NOT go into a reducer case statement.
• If false: Will the action be dispatched before or after the execution of the effect?

Q3. Combining effect arrays

• I suppose there is no problem to "combine" separate effects arrays just by concatenating them? I'd like to group my effects together with reducers and actions per module (separate folders). Maybe you should add a simple combineEffects() in analogy with combineReducers.

Q4. Thunk comparison I'm still trying to grasp Redux and get my own preferences sorted out so I can use Redux in a good way. Just so I understand - would you say that effex is like thunks, but callable via dispatch instead of calling the thunk directly?

Maybe you could extend your samples to show the above?

I'm hoping that my questions aren't too stupid ;)

[pbomb]

Hi. Let me try to answer your questions.

Q1. How do I execute an effect? 
- Via an ordinary dispatch?

Yes, each effect is configured to execute when a given type of action is dispatched. The README shows how the openAppAsync effect is executed when actions of type ActionTypes.OPEN_APP are dispatched.

Q2. It seems that the actions included in effects are not dispatched to the store.
- If true: I'll end up with a bunch of actions which should NOT go into a reducer case statement.
- If false: Will the action be dispatched before or after the execution of the effect?

The actions dispatched that trigger effects ARE delivered to the reducers before the effects are executed. That currently happens on this line. You might or might not care about this action, but I think it could be useful at times.

Q3. Combining effect arrays
- I suppose there is no problem to "combine" separate effects arrays just by concatenating them? I'd like to group my effects together with reducers and actions per module (separate folders). Maybe you should add a simple combineEffects() in analogy with combineReducers.

Combining arrays is likely common (what I'm doing), but is easy enough to do with Array.prototype.concat or the spread operator. I'm not sure I feel like this library should export a function to do that.

Q4. Thunk comparison
I'm still trying to grasp Redux and get my own preferences sorted out so I can use Redux in a good way. Just so I understand - would you say that effex is like thunks, but callable via dispatch instead of calling the thunk directly?

This middleware is similar to the thunk middleware in that they both provide ways of executing asynchronous processes within a Redux application. This library is different in that in using it, your action creators become simpler... they all just return action objects instead of some returning objects and some returning thunk functions. With the thunk middleware, although the middleware executes the async code (your thunk function), that function is defined within the action creator. With this middleware, all the effects operate explicitly within the middleware and not in the action creators.

Another difference is that it becomes easier to model multiple processes being triggered from a single user action (dispatched action).

[msageryd]

Thank you. It seems to me that this makes my actions imperative. Instead of describing what just happened, they act as commands, i.e. describes what will happen.

I don't have enough experience to tell if this is good or bad. But everyone else are telling me to stay away from imperative actions. I should instead use action creators for "commands".

On the other hand, you can change the terminology to describe what happened by naming the ui actions as "LOGIN_BUTTON_CLICKED", instead of calling an action creator named "login()". I see many people using this concept, but I don't quite understand the good about this. I don't want my UI entangled with my store at that level. What if a user can login by other means as well..

Kind of ranting, sorry.. I guess I'm just fishing for more understanding of best practice etc. I like the simplicity of Effex and I think I'll give it a try. I have stayed away from -Saga and -Loop to keep dependencies down and to not use stuff I don't completely understand.

[brentvatne]

On the other hand, you can change the terminology to describe what happened by naming the ui actions as "LOGIN_BUTTON_CLICKED", instead of calling an action creator named "login()". I see many people using this concept, but I don't quite understand the good about this. I don't want my UI entangled with my store at that level. What if a user can login by other means as well..

The idea is just that not all results of the actions can be dealt with from a reducer, so in order to keep the reducer pure, it is useful to have some construct available that allows you to perform other side effects like making a http request or saving some data to local storage.

Kind of ranting, sorry.. I guess I'm just fishing for more understanding of best practice etc. I like the simplicity of Effex and I think I'll give it a try. I have stayed away from -Saga and -Loop to keep dependencies down and to not use stuff I don't completely understand.

Yup, this is exactly the idea -- hopefully people can just read and understand this, and it doesn't introduce any new concepts to their codebase beyond saying run this async function when this action is dispatched. It won't solve all of the problems that saga solves, but like I say in README, I usually don't have those problems so I'm OK with that.

[brentvatne]

^ I renamed the issue so people who are browsing can read this and hopefully it'll answer some of the questions they might have as well.