We've got some action types, but together, let's now define a couple of different interfaces inside
of our actions index not file.
So Actions Index starts at the very top.
We will immediately import that action type from up on directory action types.
And I believe that was actually a named export.
So we will need those curly braces on there.
So for each of these different action types, we will create an interface that describes an action that
will eventually be dispatched by one of our action creators and then processed by one of our reducers.
Now, we don't really know a whole lot about what these different actions are all about.
So in other words, what would be the payload of Mousel or delete cell or insert cell before?
What are these payloads?
We don't really know yet.
We don't really have any reasonable idea, but we can probably make a reasonable assumption.
And if nothing else, we can at least put these interfaces together and have a starting point that we
can eventually add to over time.
So inside of our actions file, I'll define one interface for each of these different actions.
So first, I'll do a move, sell action.
We'll do a delete sell action.
And insert cell.
Before action, and that's what we ended up with, right cell before.
And then an update.
So action.
Then for each of these, we know that there are types are probably going to be the respective types
from our action type.
So in other words, the tight property for this interface will probably be action type dot move.
So action type move.
So.
Then for delete, sell action, you guessed it, probably something like action type, dot, delete,
sell.
Action type dot insert cell before.
And action type DOT update.
So.
OK, well, each of those are at this point, these are all kind of like give me things like you probably
could have guessed and gotten this far.
Now we need to start thinking about the payloads for each of these interfaces as well.
Again, if we can't really figure out a reasonable payload just yet, that's totally fine.
Remember, one of the points of TypeScript is to allow us to do refactor very easily.
So I think that right now we can probably just take a guess at what the different payload properties
here should be.
And then if we decide to change it over time, no problem, we'll just come back and change it.
So how about from move cell action?
What would be the payload that would we would want to provide to describe the process of moving a cell
around?
I remember when we say move cell, we're talking about reordering cells here.
So kind of moving them up and down.
Well, maybe we would want to provide an object and describe maybe the idea of the cell that we want
to move and the direction that we want to move it as well.
So maybe this should have an ID and that will be a string, presumably.
So that's going to be the idea, the cell we want to move.
I'm just assuming here that our different cells are going to have IDs because we are going to eventually
have to identify each cell uniquely.
And then maybe we should also have a direction property to say we want to move this up on our list,
so have it appear earlier on the screen or move it down the list and have it appear later?
So for direction, we could probably just make that a string and have it either be up or down.
So if I want to move it up, I want to move it up on my list or have it kind of appear first inside
the browser and down would be if I wanted it to appear later on.
I think that that's probably reasonable for our Mousel action.
Next up is delete cell.
Well, this one, I think we could probably make a really educated guess.
I think that given that we're probably going to say that every cell must have an ID, that's kind of
an assumption that we're kind of making here.
I think that for delete selection, we're probably just going to say that, well, if you want to delete
a cell, just tell us the ID of the cell you want to delete and we'll figure out some way to delete
it or remove it.
So I think that for payload, we're just going to have a string.
That's it.
It'll be just the idea, the cell that we want to delete.
Insert cell before.
Very similarly for our payload here, all we really need to know is probably which cell we want to add
this new one before.
So in this case, we'll probably just be an ID.
So go and find the cell with this ID and create a new cell right before it.
But there's little gotcha here.
Remember, we actually have two types of cells inside of application.
We have code cells and text cells.
So in addition to the ID of the cell, we want to add this new one before we probably also need to know
what type or what kind of cell this is going to be.
So I think that this payload should probably be an object that will have an ID.
There'll be a string.
And there may be a type as well, and this will be either a code cell or a text, so I'm going to say
that it must be a string of either code or text.
Now, this right here, this is something that might get us into trouble eventually.
We are saying very clearly that we're going to eventually have two types of cells inside of our application,
either code or text.
But at some point in time, we might accidentally forget exactly what types we have available to us,
what type of cell we can create.
We might accidentally think that a text cell is called maybe a markdown cell, so we could very easily
kind of make a typo in these strings.
And we would not want to have this kind of precedent of defining these types and just this one single
location, so we might eventually.
Long story short, decide to extract this definition of what types of cells we can have into some other
location.
But that will just be something we think about.
All right, and finally, update sell action.
So very similar to the one we just did, we probably just need the ID of the cell we want to update
and then maybe some new content for it or maybe some new data.
So this would be a code that we want to show in the cell or maybe the markdown that we would show inside
of the text cell.
In either case, it's really maybe content or data or something like that that we would call this.
Maybe we should say that a cell has content.
So the content is a code cells code and content is a text cell's text or essentially markdown.
So we'll say that in addition to being given some idea, the string that we want to update, we'll also
take in some content.
And this will be the new code, the new text or whatever else, or the chosen cell.
OK, so, again, I think that these might not be perfect and there might be some really big mistakes
we have inside of here, but for right now, I think that these are reasonable actions.
Now, the last thing we're going to do is create a new type of the very bottom and export it.
And it will be the union of all four of these different types, so we will do move, sell action.
Or a really union of that's what the single pipe means.
Delete cell action, I'm going to do a copy paste here just to save a little bit of time.
In union with insert cell before.
And update, so.
OK, that looks pretty reasonable.
So, again, if we need to come back and make changes to the stuff and I think that there might definitely
be some places where we do need to make changes, no problem.
We can absolutely take care of that.
But right now, I think that these are all very reasonable assumptions now that we've got our different
action types put together and we've got our different action interfaces now we can start to think about
creating these different reducers, the store itself and eventually our action creators as well.