If we have a look at our reducer here,
we see that we have all these different cases, incrementing, adding and so on,
delete, store result, all these things.
And of course I emphasize that the identifiers we're looking for here in the reducer are the identifiers
we should use in our container components, in our application where we want to dispatch these actions.
We do so of course but there always is the danger of us simply adding a tiny typo and searching for it
for hours because we don't find it. Therefore it is a good practice to outsource your action types into
constants you can use in your application so that you always just import a constant and eliminate the
danger of mistyping,
this is especially useful as your application grows.
If you only have two types of actions you dispatch, you might not need that
but for bigger applications, definitely add it. For this, I'll add a new file to my store folder and I'll
name it actions.js
and in there, we can simply export a constant which you now typically give the same name as the identifier
we'll have.
So you could have a constant which is increment and the value we assign is just that string identifier,
so we just stored that string in a constant now which we export and we do that for all our actions,
so we also have decrement here and the identifier is the same.
Now theoretically, name of the constant and identifier don't have to match but it is a good practice,
then here we have the same for add
and of course for subtract, like this and of course also for store result which we also then use as
the identifier and delete result, like this.
So now we have this extra file where we export all these actions,
this now allows us to go into the reducer and import the actions from there,
we can now simply import everything from a given file and store it in some javascript object, maybe action
types from ./actions. actionType
now is a javascript object which has all these properties here or all these consts here I should say
as properties.
So now here, we can check for case actionTypes. and now here that would be increment and the same
of course for decrement and so on.
The huge advantage of this approach simply is we're now importing our constants here
and if we mistype one constant name, we'll actually get an error by our IDE or by that build process, if
we store and save everything, I'll get an error 'export Incement' not found
so I have to fix my typo to have a working application again,
this is why you use this approach. So I'll replace all my hardcoded strings here with the action
types
I'm importing, so subtract, add and so on to eliminate the danger of mistyping here.
So actionTypes.STORE_RESULT
and of course also actionTypes.DELETE_RESULTS so that all are replaced.
And then I do the same where I dispatch them,
it of course doesn't make any sense to still have hardcoded values here because I could still mistype,
so I'll simply now import my action types here,
so import everything as action types and this name is up to you,
you can name this object whatever you want from
and now I simply move up to the store folder to the actions.js file and now I use my action types here
too for dispatching.
So here the type is actionTypes.INCREMENT, decrement and so on
and therefore, we're now always referring to that property, to the constants we are exporting in the actions
file and hence we can't mess up by mistyping or having different identifiers because now we have only
one place where we set up and store our identifiers
and that is in this actions.js file.
So now with this adjusted, the application should still work as before,
as you can see I can still add and delete results and change my counter but now, we eliminated that one
danger, one potential source of errors
therefore outsourcing your action types into a separate file from which you then import is a good practice
especially as your application grows but it doesn't have to grow that much
for this to make sense.