WEBVTT 00:00.020 --> 00:02.330 Okay, so hopefully you gave that challenge a bit of a go. 00:02.360 --> 00:03.680 It's relatively straightforward. 00:03.680 --> 00:09.590 The challenge that I settled on in the end, compared to the original challenge that I was considering, 00:09.620 --> 00:17.600 which didn't just involve using the function we have here or using this function, but making it the 00:17.600 --> 00:20.360 same function also for the review component. 00:20.360 --> 00:27.590 But the convoluted code we need to use to avoid using this kind of function as well. 00:27.590 --> 00:33.710 When this is coming from our from our confirmation token for the shipping address and payment method, 00:33.710 --> 00:40.340 preview the the types there kind of a little bit too different, especially not so much for the payment 00:40.340 --> 00:47.390 method preview, but for the address string, we have to write some pretty convoluted TypeScript code 00:47.390 --> 00:55.280 to make this function reusable across both our order types and the stripe types. 00:55.280 --> 01:00.440 So I chose not to do this, and I'm just going to keep the review component as it is. 01:00.440 --> 01:06.050 The one that we are going to focus on is the code from our Checkout Success page. 01:06.050 --> 01:11.960 So I'm just going to cut these two methods from inside here, break the application in the short term 01:11.960 --> 01:15.170 and paste them both into the util here. 01:15.260 --> 01:25.250 And I'll export the const and change the name to Format and address string. 01:25.250 --> 01:28.610 And I'll do similar for the payment one as well. 01:28.640 --> 01:38.870 I'll export const and say format payment string, and just use the document formatter to line things 01:38.870 --> 01:39.920 up a bit better. 01:39.920 --> 01:45.680 And inside the format address string, all we really need to do is just take in the address as an argument 01:45.710 --> 01:46.340 here. 01:46.610 --> 01:51.500 So I will pass in address as the name of the argument. 01:51.500 --> 01:54.560 And this is going to be of type shipping address. 01:54.560 --> 02:00.890 And we get all kinds of warnings here because line one does not exist on type shipping address. 02:00.890 --> 02:02.900 And where did I get that shipping address from? 02:02.930 --> 02:04.100 Well, I got that from stripe. 02:04.130 --> 02:05.060 Well, that's an error. 02:05.090 --> 02:09.680 I actually want the shipping address from our own types because that's the type that we're using here. 02:09.680 --> 02:12.770 So I need to get this from app models order. 02:12.800 --> 02:16.250 And now our errors have gone away. 02:16.250 --> 02:20.180 And then we can do similar fully format payment string. 02:20.870 --> 02:24.950 I'll just specify card as that's what we're using in the return statement. 02:25.310 --> 02:29.420 And then specify payment summary as the type. 02:29.420 --> 02:32.690 And then I can remove this inside here. 02:32.690 --> 02:37.370 And we don't get any warnings about we might not have the address because all of these have got the 02:37.370 --> 02:38.660 optional chaining on. 02:38.660 --> 02:39.410 Anyway. 02:39.410 --> 02:43.220 We could check for the presence of the address and then remove the optional chaining. 02:43.220 --> 02:47.810 But there's no need because this code is going to work just how we want it to anyway. 02:47.960 --> 02:53.600 Then we can go back to our checkout success page and where we were using the payment string. 02:53.600 --> 03:02.120 Here we can use our format payment string and we can pass in our order dot payment summary. 03:02.420 --> 03:09.290 And then we can do similar for the address string here and just say format address string and pass in 03:09.290 --> 03:13.340 the order dot shipping address. 03:13.340 --> 03:17.870 And then in our order detail page we can make use of this. 03:17.900 --> 03:21.710 We'll have instead of address goes here in curly brackets. 03:21.710 --> 03:24.110 We'll use our format address string. 03:24.110 --> 03:27.590 And just the same thing again we can use our order dot shipping address. 03:27.590 --> 03:37.520 And then for the payment info we can use our format payment string and order dot payment summary as 03:37.520 --> 03:38.600 its argument. 03:38.630 --> 03:39.770 Nice and simple. 03:39.770 --> 03:46.160 And if we go and take a look at our browser, we can see that we have both the shipping address and 03:46.160 --> 03:49.250 the payment info populated inside there. 03:49.250 --> 03:52.610 Now, now you might be wondering, it's like, hey, that's cheating. 03:52.610 --> 03:53.810 We didn't do the tricky one. 03:53.810 --> 03:55.380 Why didn't we do the tricky one? 03:55.530 --> 03:57.420 Well, it's actually really tricky. 03:57.420 --> 04:00.000 And I just want to highlight why it's tricky. 04:00.000 --> 04:03.720 Because if we take a look at the address, this is the tricky one. 04:04.500 --> 04:09.600 Then this shipping address is coming from a stripe type called payment intent. 04:09.600 --> 04:17.010 Shipping and working with our own types is one thing, but working with someone else's types can be 04:17.010 --> 04:19.170 tricky, especially from third party libraries. 04:19.200 --> 04:26.100 And if I just right click and go to the definition to take me to the type information for lists, then 04:26.100 --> 04:31.110 we can see that the shipping address property comes from another type called payment intent shipping. 04:31.110 --> 04:36.750 So if I right click this one and go to its definition then we have a shipping interface. 04:36.780 --> 04:41.850 Now the format of this is different to how we've defined the shipping address. 04:41.850 --> 04:47.610 We've got the address actually as a property called address and it's of type address. 04:47.610 --> 04:51.720 And we also have the name inside here that could be a string or it could be null. 04:51.810 --> 04:54.810 And then we can go and take a look at the address definition. 04:54.810 --> 04:57.180 And we've got our different address properties. 04:57.180 --> 05:00.090 And these look familiar to what we've used in our code. 05:00.120 --> 05:07.380 When it becomes really tricky is if I go back to the util folder, now that we've got that snippet of 05:07.380 --> 05:14.130 information fresh inside our minds, and go back to our util, what we would need to use here for our 05:14.130 --> 05:18.630 format address string, we would need to use a union type, for example. 05:18.630 --> 05:20.280 And this would need to be of type. 05:20.280 --> 05:23.610 The one that we just looked at would be of type payment intent. 05:23.610 --> 05:26.640 And then in square brackets it would be shipping. 05:26.760 --> 05:32.610 And then we get all sorts of problems inside here, because our return type is not going to match. 05:32.610 --> 05:35.850 The only one that doesn't give us an error is the address name. 05:35.850 --> 05:38.220 So then we need to start thinking about type guards. 05:38.220 --> 05:40.590 And we could say okay fine, we know about type guards. 05:40.590 --> 05:47.070 Now we could say if the address or if we're looking for an address. 05:47.070 --> 05:52.710 For instance, when we were looking at this, we know that the payment intent shipping type has an address 05:52.710 --> 05:54.150 as one of its properties. 05:54.150 --> 06:02.100 So we could look for address in the address that we're using as an example. 06:02.130 --> 06:08.190 And even then we get further problems because we don't know if this exists because of the type that 06:08.190 --> 06:10.260 the payment intent shipping is using. 06:10.260 --> 06:12.870 If we hover over this, then this could be null. 06:12.900 --> 06:17.940 So then we need to before we even get to that stage, we need to check for the presence of the address. 06:17.940 --> 06:20.880 And if we do not have the address then we return. 06:20.880 --> 06:27.240 In this case I'll just demonstrate an empty string, but then we can start using the address properties. 06:27.750 --> 06:32.550 So then we could say something like okay, now we know that this is going to be a type of payment intent 06:32.550 --> 06:33.330 shipping address. 06:33.330 --> 06:40.230 Because if I take a look at the let's see the address dot properties. 06:40.230 --> 06:45.630 Now we've got the properties for the address dot address and we've got the name. 06:45.630 --> 06:53.970 But what we'd end up doing is really just using a return statement inside here to then return a format 06:53.970 --> 06:59.160 string based on the fact we're using this, and we'd end up with a similar amount of code to what we've 06:59.160 --> 07:00.090 got anyway. 07:00.090 --> 07:06.630 And it's just overcomplicating things because I know or we know, and maybe that will change in future 07:06.630 --> 07:08.730 if we expanded this application. 07:08.730 --> 07:12.030 The only place we're using that is inside this review component. 07:12.030 --> 07:15.720 So I cheated a little bit by not going as far as I could do with this. 07:15.720 --> 07:17.130 I'm not going to do it this way. 07:17.130 --> 07:21.240 I'm just going to keep things simple inside this component. 07:21.240 --> 07:28.260 And I didn't want to make this challenge overwhelmingly difficult because it can be if we go down this 07:28.260 --> 07:34.620 approach of trying to make a union type out of this and then use type guards, I think simplicity and 07:34.620 --> 07:42.840 clarity is preferable on a training course than ultimate conciseness of not repeating ourselves at every 07:42.840 --> 07:43.500 step. 07:43.500 --> 07:46.560 So now we've got our order detail page in place. 07:46.560 --> 07:52.780 We've still got a disconnect between stripe and what we're doing from our checkout perspective, because 07:52.810 --> 08:00.220 our order status inside here is pending, and the only way we can change that is by getting stripe to 08:00.250 --> 08:05.050 notify our API that the order has been paid for. 08:05.500 --> 08:09.880 And in order to do that, we need to start thinking about these things called webhooks. 08:09.880 --> 08:18.580 And stripe can send an HTTP request to our API to notify our back end that the payment has been made, 08:18.580 --> 08:25.960 because as far as payments are concerned, we don't communicate between our browser client and our own 08:25.990 --> 08:29.320 API because we don't want to touch their payment card details. 08:29.320 --> 08:32.350 That's communication directly between client and stripe. 08:32.350 --> 08:38.110 So what we're going to take a look at next is we're going to take a look at webhooks. 08:38.110 --> 08:45.490 And we're going to create an endpoint that stripe can use to notify our API that something has been 08:45.490 --> 08:46.330 paid for. 08:46.330 --> 08:48.460 And we'll take a look at that next.