Okay.
Our next step is to take what we have here and use this to update our product form.
And inside here we're going to create a method to submit what we're doing from our form.
Now we do need to think about caching as per usual with RTK query.
Because once again then when we do create a product inside here in the inventory, if I cancel out of
this and go back to the inventory, then this has been cached by RTK query.
Now caching is local to the user's browser.
And whatever we do from our admin, if we have several users viewing the catalog, then what we do as
admin is not going to affect that, because what we do only affects the admin user's browser.
Now, the default caching behavior for RTK query is to cache for 60s.
So if an admin adds a product, then that's not going to appear in the user's browser other user's browsers
until they've moved away from the catalog component or any component that uses the fence products for
60s, and that's not something I'm going to worry about with this admin functionality.
But what we will do is make sure that the admin inventory is updated after a product has been edited
or been created.
So that's what we'll aim for in this lesson.
So let's go back to our product form.
And in fact, in order to enable that functionality, let's just go up to our inventory page first.
And there's another thing that we can use from our Use Fetch products query that we haven't used yet.
And that is the fetch function.
And this does what you would expect it to do.
It's going to force this query to be refetched from our API.
So it's just an alternative way of ensuring that we're working with the latest data rather than cached
data.
And where we need to use this function is inside our product form.
So let's just move a couple of these things down so I don't go off the edge of the screen and we're
going to pass down to our product form.
Also the Refetch function.
So I'm going to call it Refetch and set it equal to refetch.
So this will be available inside our product form.
And let's head over to the product form.
We'll just add that to our props as well.
So I'll specify refetch.
And this takes no parameters and returns void.
That's its signature.
And then we'll just pass it in as an additional property inside here that we can utilize.
Now another thing that I want to think about doing inside here as well is cleanup.
When we create that preview URL inside here, that stays in memory until we clear it out.
So we can use our Useeffect to add a cleanup function in here as well, so that we remove that created
object URL when our component is no longer mounted.
So below the if statement here then in order to use a cleanup function, we specify return and we provide
this with a function.
What do we want to happen when this component is disposed of?
Well, we'll check to see if we have the watch file.
And if we do then we'll use URL and revoke object's URL.
And we'll pass in the watch file dot preview.
And then we've got something else to add to our dependencies here which is the watch file.
So we'll just add this as well.
And then we can update our Onsubmit method.
So we'll make this async.
And then instead of console dot logging the data we'll add a try catch block inside here.
And we'll check to see if we have the product.
If we do have the product that means we're updating.
So we need to use our hooks that we get from our admin API.
So I'm going to have const in square brackets create products equals And we'll use the use create product
mutation.
And I'll just copy this down.
And the second one can be update products.
And the hook we use for this will be the use update product mutation.
And then inside our try block we can check to see if we have the product.
And if we do then we're updating a product.
So we'll specify a weight and then update product in parentheses.
And then we'll pass this as an object because we need the ID and also the data here as well that's inside
our form.
So we'll specify ID and set that to be the product.id.
And then we'll pass it the data as the second parameter there.
If we don't have a product we'll add an else statement.
That means we're creating a product.
And we can just use await create products and pass data in as the second parameter.
Now, because we're inside our product form after we have submitted, then we will cancel the edit mode,
so we'll set the edit mode to be false.
And then we can use the Refetch function, which is going to go out and get the updated list of products
from our API.
And if we do have an error, let's just console dot log any error.
So what we can also get from react hook form is something that we can use for a loading indicator if
something is being submitted.
So we'll actually use a loading button in here even though it is using our own API.
Which means we're going to see the loading indicator at the top anyway.
But just for a demonstration of this as well, because I don't think we've used it yet from our form
state.
We can also get the is submitting flag and we can utilize this for a loading button for instance.
So let's come down to our buttons inside our form.
And for this one we're going to change it to a loading button that we get from Mui lab and just make
sure that has been brought in.
It has not.
So I'm going to add that import and let's move some of this stuff down.
And I will give it the loading property and set it equal to is submitting.
So is it that easy.
Have we now enabled this functionality.
Well we're going to have some issues.
And let's go and take a look at what the issues are.
And then in the next lesson we'll look at addressing those issues.
And what could go wrong with this.
Well let's take a look.
And I'll just pick on the update one.
Because obviously I don't need to fill out the entire form if I do take a look at that one.
And if I edit the product and I just make a small change to angular blue boots, I set it to one and
I come down here, don't change anything else, but then I click submit.
What's going to happen here?
Well, it looks like something happened.
I got redirected back to the inventory, but my angular blue boots hasn't updated.
If I refresh the page, is it just a caching issue?
It appears not.
That's the data that's coming back from our API.
So what happened here is we failed silently.
We gave the admin user the impression that something happened, but nothing really did happen.
And let's go and take a closer look at exactly what happened there.
So we need to open up our Chrome DevTools to get the information here.
And if I click on edit again I'll just repeat what I did before.
I'll change this to angular two this time just in case there's an issue with the number one.
There isn't of course I'll click submit and then we'll see what happens.
Okay, so what happened is we failed validation on the API.
Huh.
Well, how did we fail?
Validation.
Maybe we didn't send up the information in our request.
So we've got the error.
We've got the validation errors.
They're all coming into our console.
We're not displaying them on our form is the behavior we need to do to get validation appearing on our
form.
But if we want to take a closer look at the request, then we can click on this link here.
And it takes us to our network tab.
And then we've got our request, the failing request the one with the 400.
And if we click on this then we get the full details about the request.
Incredibly useful information when you're troubleshooting because the browser if we don't look at Chrome
DevTools the browser doesn't tell us anything.
So we absolutely need to come into here and take a look at what happened.
Now we know this functionality worked in postman.
We know that we've seen it working.
So really what we're looking for is what's the difference between this request and a postman request.
And if I take a look at the payload here, well we can see that we're sending up the brand, the description,
all of the properties that we require in our update product, DTO.
Yet we've still got a validation error.
And if we take a look at the preview and the errors, then we can see all of the different errors inside
here.
Validation errors.
It looks like we haven't sent anything up to our API at all.
But there's a difference between what we're doing here.
Versus what's happening in postman.
If I go back to the headers and I take a look.
At the request headers, then I'm sending up this content as application JSON.
We can see that there in the content type.
That's the default behavior for what we're doing.
If we go back and take a look at postman and we take a look at editing a product with a file, we're
sending this data up as form data.
It's not going up as application JSON.
And if I take a look at the console and do I have an edit inside here I've got this post request.
This should suffice.
And if we take a look at the content type for this one, then we can see it's multipart form data.
So there's a difference between what we're doing in postman versus what we're doing in our browser.
And what we'll take a look at next is how we can address that difference and ensure we send up the data
from our browser using the correct format.
And that's coming up next.