1 00:00:01,150 --> 00:00:02,760 Let's go back over to our common library. 2 00:00:02,770 --> 00:00:07,060 We're going to define this enum of order status to describe all the possible statuses that in order 3 00:00:07,060 --> 00:00:13,840 can have back inside my editor I'll find my common directory inside they're going to find s our C then 4 00:00:13,840 --> 00:00:20,470 events and inside of events I'm going to make a new folder called types and then inside of types I'll 5 00:00:20,470 --> 00:00:27,120 make a new file called Order dash status dot t s inside of order status. 6 00:00:27,130 --> 00:00:33,680 I'll then write out export enum order status so in total we're gonna say that in order can have four 7 00:00:33,710 --> 00:00:38,690 different possible states only for I can first write out all these different states that in order can 8 00:00:38,690 --> 00:00:42,560 be in and then we'll put in some comments to describe the purpose of each of them. 9 00:00:42,720 --> 00:00:46,480 So first is going to be created canceled 10 00:00:50,650 --> 00:00:52,300 awaiting payment 11 00:00:56,390 --> 00:00:57,260 and complete 12 00:01:00,900 --> 00:01:04,530 so these are the only four possible statuses that an order can ever have. 13 00:01:04,580 --> 00:01:07,000 It's not gonna put on a comment for each one. 14 00:01:07,000 --> 00:01:10,800 So when is something going to be or when is an order going to have a status of created. 15 00:01:10,870 --> 00:01:16,540 We're gonna say that in order has a status of created when the order has been created. 16 00:01:16,660 --> 00:01:26,860 But the ticket it is trying to order has not been reserved. 17 00:01:27,870 --> 00:01:33,150 So it turns out as you'll see in a little bit whenever someone creates an order we're not going to necessarily 18 00:01:33,150 --> 00:01:38,640 immediately have full confirmation that a ticket or the ticket the user trying to purchase is actually 19 00:01:38,670 --> 00:01:40,260 100 percent reserved. 20 00:01:40,290 --> 00:01:45,490 It turns out that there actually is a race condition that we need to think about very deeply. 21 00:01:45,600 --> 00:01:50,130 So whenever an order gets created we're going to say well we think that we have reserved the ticket 22 00:01:50,160 --> 00:01:52,170 but we don't actually know for sure. 23 00:01:52,260 --> 00:01:57,330 There's kind of a difference between a order reserving a ticket and a ticket being actually available. 24 00:01:57,450 --> 00:01:59,160 We'll dive more into this over time. 25 00:01:59,160 --> 00:02:05,390 Right now it's going to say that whenever a order has been created by default it will be simply created. 26 00:02:05,400 --> 00:02:06,420 Next up is canceled. 27 00:02:06,930 --> 00:02:15,310 So a order will be in the state of cancelled any time the ticket the order is trying to reserve has 28 00:02:15,310 --> 00:02:25,820 already been reserved or when the user has cancelled the order so kind of two scenarios here. 29 00:02:25,890 --> 00:02:30,280 The first one is kind of a reference to what I just mentioned around this created case. 30 00:02:30,420 --> 00:02:35,850 So it is possible for a user to create an order but for it to not actually successfully reserved the 31 00:02:35,850 --> 00:02:37,640 ticket that the order was for it. 32 00:02:37,680 --> 00:02:41,900 And again it goes to that kind of race condition that we'll discuss in a little if that's the case. 33 00:02:41,940 --> 00:02:45,270 If we kind of fail to reserve the ticket we're gonna fall into this cancelled case. 34 00:02:45,870 --> 00:02:52,320 And naturally if a user decides to cancel the order we will also market as canceled now awaiting payment 35 00:02:52,440 --> 00:02:59,370 is going to occur whenever the order has successfully reserved the ticket 36 00:03:02,290 --> 00:03:05,760 and finally complete Mike this thing is complete. 37 00:03:05,760 --> 00:03:16,640 Any time the order has reserved the ticket and the user has provided payment successfully there is actually 38 00:03:16,640 --> 00:03:17,430 one of the case here. 39 00:03:17,450 --> 00:03:24,980 I mentioned ah I failed to mention around cancelled the other possibility is if the order expires before 40 00:03:24,990 --> 00:03:28,520 payment Well we forgot that very important case. 41 00:03:28,540 --> 00:03:32,680 So if say 15 minutes goes by and we don't get any payment from the user then we're going to mark the 42 00:03:32,680 --> 00:03:37,250 order as canceled as well as those that cancelled is kind of a catch all. 43 00:03:37,420 --> 00:03:40,180 So we're kind of capturing these three different cases. 44 00:03:40,180 --> 00:03:45,610 So when we fail to do the reservation when the user cancels the order or when it expires as well all 45 00:03:45,610 --> 00:03:47,430 three those are under one case right here. 46 00:03:47,470 --> 00:03:52,000 If you wanted to you could definitely split these out to three different statuses to get a better idea 47 00:03:52,210 --> 00:03:56,730 as far as analytics goes of why orders are failing to actually be processed. 48 00:03:56,780 --> 00:04:00,730 Maybe something I'm just mentioning we're not going to do it because essentially for our purposes an 49 00:04:00,730 --> 00:04:06,190 order is either a progressing through the stages and getting towards complete or it has failed in which 50 00:04:06,190 --> 00:04:09,280 case we're gonna market as simply cancelled. 51 00:04:09,280 --> 00:04:09,910 So this is it. 52 00:04:09,910 --> 00:04:13,720 These are the four statuses we can possibly have around in order. 53 00:04:13,720 --> 00:04:15,860 They're not going to save this file. 54 00:04:16,030 --> 00:04:20,100 We need to now make sure that we export this enum from our common module. 55 00:04:20,140 --> 00:04:25,840 We then need to republish the module and then update the common module inside of our orders project. 56 00:04:27,510 --> 00:04:32,340 So step one let's make sure that we actually export order status so inside the common modules index 57 00:04:32,350 --> 00:04:39,110 not to yes file I will add in and export from events. 58 00:04:39,170 --> 00:04:39,620 Order. 59 00:04:39,670 --> 00:04:40,870 Status. 60 00:04:40,890 --> 00:04:41,470 Yeah. 61 00:04:41,520 --> 00:04:42,390 That was easy. 62 00:04:43,540 --> 00:04:49,450 I'm going to save this file was it going to close the order status and then go back over to my terminal 63 00:04:50,860 --> 00:04:58,800 or change into my common directory and I'll do an NPM run pub inside their as usual. 64 00:04:58,810 --> 00:05:04,660 Gonna commit build increment version push off to NPM. 65 00:05:04,690 --> 00:05:08,630 All that kind of good stuff once the thing is all done. 66 00:05:08,700 --> 00:05:15,190 I'll then change over to orders and do an NPM update. 67 00:05:16,470 --> 00:05:17,550 As tickets. 68 00:05:17,780 --> 00:05:27,500 Common naturally makes you change that to your organization name they will run that and then we should 69 00:05:27,500 --> 00:05:30,650 just really confirm make sure we get the correct version on the update. 70 00:05:30,680 --> 00:05:32,720 So I just published version 14. 71 00:05:32,810 --> 00:05:34,430 There's version 14 right there. 72 00:05:34,430 --> 00:05:37,630 Definitely feel like I got the right version gold. 73 00:05:37,660 --> 00:05:43,350 Now we can go back over to our Ed and back inside of our orders project the order service will find 74 00:05:43,350 --> 00:05:48,210 the order model file which we are just working on then at the very top. 75 00:05:48,530 --> 00:05:51,290 We're going to import the order status enum 76 00:05:54,940 --> 00:05:59,420 from our common module. 77 00:05:59,460 --> 00:06:04,380 I've got a little error here around the import it's just kind of an issue out of the US Code. 78 00:06:04,410 --> 00:06:08,190 Every now and then whenever you update a type definition file which is pretty much what's going on right 79 00:06:08,190 --> 00:06:08,870 here. 80 00:06:08,880 --> 00:06:12,960 Yes code is not going to understand that we've actually update this module right away. 81 00:06:13,110 --> 00:06:18,240 So to get the US go to understand what's going on here you can do a command shift P to open the command 82 00:06:18,240 --> 00:06:18,900 pallet. 83 00:06:18,900 --> 00:06:26,380 If you're on Windows I believe that's give me control ship P and then you can search for reload window. 84 00:06:26,440 --> 00:06:27,560 Go ahead and hit enter. 85 00:06:27,580 --> 00:06:28,720 That's essentially just going to reload. 86 00:06:28,740 --> 00:06:33,530 Yes code that's going to force it also to reload all the type definitions and now you'll notice that 87 00:06:33,530 --> 00:06:35,550 I don't have an air around that import anymore. 88 00:06:37,170 --> 00:06:38,790 Now let's make use of this order status. 89 00:06:38,790 --> 00:06:44,190 We're going to apply it to the order attributes interface and order document to severely restrict what 90 00:06:44,190 --> 00:06:46,340 the status of an order can be set to. 91 00:06:46,440 --> 00:06:51,100 So rather than allowing an order to have a any arbitrary status so long as it is a string we're going 92 00:06:51,100 --> 00:06:57,800 to say that the status property must be one of the possibilities listed inside of order status and we'll 93 00:06:57,810 --> 00:06:59,680 do the same thing for the order doc as well. 94 00:07:02,970 --> 00:07:09,060 And then finally we can actually also encode on our Mongo schema this requirement as well. 95 00:07:09,060 --> 00:07:15,270 So technically the interfaces up here should be enough to capture any kind of erroneous case but we 96 00:07:15,270 --> 00:07:20,130 can also add in some validation on Mongoose aside to make sure that anytime someone tries to change 97 00:07:20,190 --> 00:07:25,560 or set this status properly right here my guess I'll make sure that it gets set to one of several possible 98 00:07:25,560 --> 00:07:35,250 values so on status I'm gonna add in another key here of Enum object values and then put in the order 99 00:07:35,250 --> 00:07:37,770 status in the. 100 00:07:37,850 --> 00:07:42,920 Now whenever we tried to set update whatever the status property mongoose will make sure that we set 101 00:07:42,920 --> 00:07:49,470 it to one of the values listed inside of that enum one other thing that we might actually want to do 102 00:07:49,470 --> 00:07:54,600 is provide a default value for this to make sure 100 percent that this thing really truly always gets 103 00:07:54,600 --> 00:07:54,930 set. 104 00:07:55,560 --> 00:08:00,110 So by default we could say that every order gets created with a default status of created. 105 00:08:00,180 --> 00:08:04,900 So to say that a write in defaults then order status not created. 106 00:08:04,920 --> 00:08:10,900 Like so this really is 100 percent optional because we've got now to type checks at the top of the file. 107 00:08:10,920 --> 00:08:12,710 We've also got the e num right here. 108 00:08:12,900 --> 00:08:14,680 So not super necessary. 109 00:08:14,730 --> 00:08:16,640 We're always gonna make sure we set that order status. 110 00:08:16,650 --> 00:08:20,660 But you can just add that in if you wish. 111 00:08:20,700 --> 00:08:21,520 ALEX Good. 112 00:08:21,540 --> 00:08:25,080 That's definitely to solve all this issue around handling the order status. 113 00:08:25,080 --> 00:08:26,240 It's now quick pause right here. 114 00:08:26,250 --> 00:08:28,740 We'll come back the next video and discuss the other property on here. 115 00:08:28,770 --> 00:08:30,870 That ticket property and how that thing is gonna be set.