Let's go back over to our common library.
We're going to define this enum of order status to describe all the possible statuses that in order
can have back inside my editor I'll find my common directory inside they're going to find s our C then
events and inside of events I'm going to make a new folder called types and then inside of types I'll
make a new file called Order dash status dot t s inside of order status.
I'll then write out export enum order status so in total we're gonna say that in order can have four
different possible states only for I can first write out all these different states that in order can
be in and then we'll put in some comments to describe the purpose of each of them.
So first is going to be created canceled
awaiting payment
and complete
so these are the only four possible statuses that an order can ever have.
It's not gonna put on a comment for each one.
So when is something going to be or when is an order going to have a status of created.
We're gonna say that in order has a status of created when the order has been created.
But the ticket it is trying to order has not been reserved.
So it turns out as you'll see in a little bit whenever someone creates an order we're not going to necessarily
immediately have full confirmation that a ticket or the ticket the user trying to purchase is actually
100 percent reserved.
It turns out that there actually is a race condition that we need to think about very deeply.
So whenever an order gets created we're going to say well we think that we have reserved the ticket
but we don't actually know for sure.
There's kind of a difference between a order reserving a ticket and a ticket being actually available.
We'll dive more into this over time.
Right now it's going to say that whenever a order has been created by default it will be simply created.
Next up is canceled.
So a order will be in the state of cancelled any time the ticket the order is trying to reserve has
already been reserved or when the user has cancelled the order so kind of two scenarios here.
The first one is kind of a reference to what I just mentioned around this created case.
So it is possible for a user to create an order but for it to not actually successfully reserved the
ticket that the order was for it.
And again it goes to that kind of race condition that we'll discuss in a little if that's the case.
If we kind of fail to reserve the ticket we're gonna fall into this cancelled case.
And naturally if a user decides to cancel the order we will also market as canceled now awaiting payment
is going to occur whenever the order has successfully reserved the ticket
and finally complete Mike this thing is complete.
Any time the order has reserved the ticket and the user has provided payment successfully there is actually
one of the case here.
I mentioned ah I failed to mention around cancelled the other possibility is if the order expires before
payment Well we forgot that very important case.
So if say 15 minutes goes by and we don't get any payment from the user then we're going to mark the
order as canceled as well as those that cancelled is kind of a catch all.
So we're kind of capturing these three different cases.
So when we fail to do the reservation when the user cancels the order or when it expires as well all
three those are under one case right here.
If you wanted to you could definitely split these out to three different statuses to get a better idea
as far as analytics goes of why orders are failing to actually be processed.
Maybe something I'm just mentioning we're not going to do it because essentially for our purposes an
order is either a progressing through the stages and getting towards complete or it has failed in which
case we're gonna market as simply cancelled.
So this is it.
These are the four statuses we can possibly have around in order.
They're not going to save this file.
We need to now make sure that we export this enum from our common module.
We then need to republish the module and then update the common module inside of our orders project.
So step one let's make sure that we actually export order status so inside the common modules index
not to yes file I will add in and export from events.
Order.
Status.
Yeah.
That was easy.
I'm going to save this file was it going to close the order status and then go back over to my terminal
or change into my common directory and I'll do an NPM run pub inside their as usual.
Gonna commit build increment version push off to NPM.
All that kind of good stuff once the thing is all done.
I'll then change over to orders and do an NPM update.
As tickets.
Common naturally makes you change that to your organization name they will run that and then we should
just really confirm make sure we get the correct version on the update.
So I just published version 14.
There's version 14 right there.
Definitely feel like I got the right version gold.
Now we can go back over to our Ed and back inside of our orders project the order service will find
the order model file which we are just working on then at the very top.
We're going to import the order status enum
from our common module.
I've got a little error here around the import it's just kind of an issue out of the US Code.
Every now and then whenever you update a type definition file which is pretty much what's going on right
here.
Yes code is not going to understand that we've actually update this module right away.
So to get the US go to understand what's going on here you can do a command shift P to open the command
pallet.
If you're on Windows I believe that's give me control ship P and then you can search for reload window.
Go ahead and hit enter.
That's essentially just going to reload.
Yes code that's going to force it also to reload all the type definitions and now you'll notice that
I don't have an air around that import anymore.
Now let's make use of this order status.
We're going to apply it to the order attributes interface and order document to severely restrict what
the status of an order can be set to.
So rather than allowing an order to have a any arbitrary status so long as it is a string we're going
to say that the status property must be one of the possibilities listed inside of order status and we'll
do the same thing for the order doc as well.
And then finally we can actually also encode on our Mongo schema this requirement as well.
So technically the interfaces up here should be enough to capture any kind of erroneous case but we
can also add in some validation on Mongoose aside to make sure that anytime someone tries to change
or set this status properly right here my guess I'll make sure that it gets set to one of several possible
values so on status I'm gonna add in another key here of Enum object values and then put in the order
status in the.
Now whenever we tried to set update whatever the status property mongoose will make sure that we set
it to one of the values listed inside of that enum one other thing that we might actually want to do
is provide a default value for this to make sure 100 percent that this thing really truly always gets
set.
So by default we could say that every order gets created with a default status of created.
So to say that a write in defaults then order status not created.
Like so this really is 100 percent optional because we've got now to type checks at the top of the file.
We've also got the e num right here.
So not super necessary.
We're always gonna make sure we set that order status.
But you can just add that in if you wish.
ALEX Good.
That's definitely to solve all this issue around handling the order status.
It's now quick pause right here.
We'll come back the next video and discuss the other property on here.
That ticket property and how that thing is gonna be set.