Now we restructured our actions in the last lecture,
now I want to dive into what we actually put into the action creators.
It's obviously easy for asynchronous code,
the only place where we can execute asynchronous code is in our action creator,
it's what redux-thunk is made for and it's the common and best practice pattern if
you need to reach out to a server to fetch data from it and thereafter store it in your store,
definitely do that with the action creator. Send your HTTP request here instead of set timeout and once
the answer is there, the response is there,
store it in your store, you will see this in action in the course project of course.
However you can of course put much more logic into your action creators, think about saveResult,
we save our result there, we get it as an argument and we simply return an action where we pass it on
as a payload.
Now this is a very dry action creator,
it doesn't do anything else but just return object with the unchanged response,
result, excuse me.
Now obviously what we could do is we could create a constant maybe name it updatedResult and set it
equal to result times two.
Now obviously, that doesn't make this much sense here but we can theoretically alter anything you want
here and you might have transformations which make more sense,
maybe we want to update some id, we want to add a user name and we then pass on our updatedResult.
The thing is this happens upon saving the result,
keep that in mind,
our application still works. If I store that, we stored 20 because we updated the result by multiplying
it with two.
Now we have logic in the action creator
and this might be valid logic instead of some nonsense operation like this one,
the thing is you could of course also execute the same logic
so let me revert this to the previous state of just passing on response.
You could execute that same logic if you need to transform the data before storing it in the state which
is perfectly fine which might happen.
You can execute that same logic of course in your reducer, here
storeResult,
here we concatenate the result and store the value and
now obviously, nothing is keeping us from multiplying this with two here,
if I do it there in the result reducer,
now if I save 10, we still store 20 in the store as you can see
but now we change it at a totally different place,
we change it in the reducer.
Now as I said, this operation here might not make that much sense but you'll often have cases where you
really want to change something before you store it in the state,
you'll not always get the value you just want to pass on,
where should you then change it? In the reducer
as I show you here, you can of course also run some code before returning here, change data or in the action
creator
like I showed you before, here what I commented out.
Both works,
what's better? Let's take a closer look.
In the end, the question comes down to where to put the logic,
we have action creators and reducers as options. Now
action creators as you learned are great for running async code when you dispatch an action, reducers
on the other hand only are able to run synchronous code and are pure, input in updated state out. Reducers
however keep that in mind, are meant to be the place where you update the state,
this is one core redux concept. Action creators are not core redux concept, a core concept are actions,
these javascript objects with a type and a payload. So the reducer is the core concept and the whole idea
behind redux is that the reducer is the only thing which updates the state, action creators shouldn't
prepare the state too much
for that reason because it should be the reducer which does the update but there of course is also a difference
between updating the state which essentially just means returning a new object which makes up our
state and changing the data which goes into the state.
Still you can find arguments for both directions,
I lean towards putting the logic into the reducer and not too much logic into the action creator.
Asynchronous code has to go there but once you got back the data from the server you might need to reach
out, you can of course transform it in the action creator and you should do that to a certain extent
but once you've got data that is relatively clean, you should hand it off to the reducer.
And if you then still need to manipulate it, for example by taking 8 times 2 or anything like that, in my
opinion that should go into the reducer.
Now you will also find arguments for the other side and in the end, it's your decision. If you choose
one approach, stick to it though, don't change it,
don't put a lot of logic in one action creator, just to then have a lot of logic in another reducer.
Be consistent and decide, where do you want to transform and prepare your data, the action creator or reducer,
I recommend the latter
but ultimately it's up to you,
just take a consistent route.