Let's make sure we've got an index route of sorts that shows the user a list of all the different orders
that belong to them.
So back inside, my editor going to find my pages directory.
Inside there is orders.
And inside of that, I'm going to make a new file of Index J.S..
So if we now go to just flash orders, it's going to show the component that we export from this index,
J.
S file.
At the very top, let's make an order.
Index components.
And right now, Distri turn a d'Hiv.
It says order index.
I will export default order index.
And then let's define a get initial props function.
This is where we're going to fetch our initial list of orders.
The order index not get initial props.
This function will be called with a context, argument and client.
We don't only care about context in this case.
We really just care about the client.
We want to make a request where order service and get the list of orders.
We'll get some data from a weight line to get API.
I'll then return an object with orders that references that data.
Now, before we test this out, we should probably go take a little quick peek at our order service
and make sure that it only returns orders related to the user who is making the request.
So back inside of my orders service, I'm going to take a look at my roots directory and find index
dot to yes inside there.
And it looks like.
Yep.
We definitely filter by the user I.D. or the person who is making the request.
Now, back inside the index J.S. file, we can receive that list of orders as a prop into order index.
And then maybe rather than returning to dive right here that we just put together.
Maybe we should just return some kind of you well with the list of allies inside of it.
That just list out all the different orders and their status.
So I'm going to go ahead and just delete that div right there.
Cyper making you write it even though we just deleted it.
I got a place to well.
That side, they're going to place some curly braces.
I'm going to map over my list of orders.
And for every order, I'm going to render an ally that displays maybe the title of the ticket that is
associated with this order and the order status as well.
So orders dot map and for every order.
I'm going to return an ally.
A place to keep up on that ally, though, ordered an I.D. will be Michy.
And then inside of the ally itself, I'm going to print out the order ticket title.
And then a little dash and then I'll print out the status of the order, the order dot status.
Get let's say this and see what it looks like.
It's going to refresh the page.
While Achmat slash orders and there is our list, it looks like I've had many attempts to purchase that
first client ticket and then eventually I completed one.
So that is my order right there.
That has been completed.
I own that ticket.
And then finally, between last video on this one, I tried to create an order for the other ticket
I created and I let it time out as well.
And so it got marked as canceled.
Well, well, the very last thing that I would like to do is to make sure that after you successfully
purchase a ticket.
So in other words, we provide a payment for an order.
I would like to redirect the user over to this big list of orders to be pretty straightforward.
So let's just do it right now.
I going to go back over to our page.
Or orders show, though, inside the orders folder.
I'll find the order I.D. file.
That is our order show component.
Rather than doing a console log of the payment that we got back, let's instead redirect the user over
to the big list of orders and they should hopefully see that the order they just kippin that they had
just created gets marked as complete.
To redirect the user, we're going to again import Rueter from next router at the top.
And then instead of doing that console log of the payment, I don't really need that payment argument.
Or the council log.
I'm going to replace it with router dot push to slash orders.
Let's now try to purchase another ticket.
And after we purchase the ticket, we should be redirected back over to the list of orders.
I'm going to go back to my main landing page.
So here's the ticket I want to buy.
If you do not have a ticket at this point, just go ahead and create one really quickly.
So I can tell you that tickets are purchased at.
Going to pay off my credit card.
And remember, our magic credit card number is or two four two four two one in my date.
The security code and pay.
So now I should be automatically redirected back over to my big list of orders.
And there is my completed order right there.
And so that ticket, in theory, belongs to me.
And that's pretty much it.
Well, I know that these styling on this application is not great at all.
And some of the screens are just plain confusing, like the screen right here, kind of unclear what
is going on.
But I'm going to leave improvements to the styling and changing some the mechanics around us.
Up to you, because really there are an infinite number of ways that we could further develop this application.
The other thing on dimensioned is that when a user purchases a ticket, we don't really have any information
or anything like that being exposed to the user.
There's not really like US ticket that they really receive in the e-mail or anything like that.
We're solely saying that once the order has been paid for.
That's it.
The ordered me the ticket now belongs that user.
And that's kind of the end of the entire workflow.
That's a little bit not that great.
You know, we could have gone a little bit further in developing that.
But again, these are some things I had to leave up to you so you can add on maybe an additional service,
maybe some additional features or something like that and expand out this application.
So we're gonna call the front end.
Pretty much good for right here.
We're gonna take a pause right here.
Continue in just a minute.
I mean, to start to take a look at adding in some test automation and deployment options for our application.