In the last video we successfully edited a stream.
I'd definitely change the description.
This one right here.
But when we came back to the streamlets page I no longer see the buttons to edit and delete the stream.
So that seems a little bit off but I bet we can figure out what's going on here.
I'm going to open up my network request tab right here.
I'm not going to refresh the page and take a look at the request to get my list of streams from the
slash streams and point on my API when I select that request or then open up response right here or
preview either one inside of this list of streams.
Here's my Stream right here I've got the title and the description.
I've also got the idea.
Remember we only show those edit and delete buttons if the user id of the stream is equal to the currently
signed in user.
So I don't see any user ID right here.
So something seems a little bit off.
Well let me just come out and tell you exactly what's going on here.
I want you to see this little air right here to kind of clean clear up a very common misconception in
the world of rest requests restful requests are restful conventions.
All right.
So I showed you this chart a while ago right here.
MEMBER We spoke about restful conventions with this.
We spoke about how we can make a get request to streams to get a list of all of our records.
We spoke about making a post request to stream's to create a record and then I had told you that to
update a record we were going to make a polite request to stream's slash and then the ID stream that
we were trying to update.
Now a lot of documentation you're going to read is going to say exactly that but a put request actually
has a little side effect to it.
That is very commonly not well implemented in a lot of back and API.
So here's what really goes on when you make a put request.
The actual thing that happens is whatever properties you put inside the body of that request are going
to replace all the properties inside of the record that you're trying to update.
So in other words when we just made our update request were are put requests on submission that form.
We posted the title and description property right.
We just made a big deal about saying that we were only going to take the title and the description out
of the form and attempt to submit that to the back end API.
The problem is that when we made our request to our API the API said oh OK I see a title and description
and I see you made a put request so I'm going to take all the different properties inside the stream
the title The ID the description and the user id as well.
And I'm going to replace them with just the properties that you posted or put up to this API.
So we put a tile and description that meant that we took the existing title description and user ID
and replace it with just the new title and description.
The one property that is usually immune to this is the id property.
So essentially when we made our Put request we did not include a user ID inside of that update and we
did that for very good reasons that we just discussed.
But our back and AAPI interpreted that as saying oh you no longer want a user ID and so it just dropped
off the user id entirely.
And that's why we don't see the User ID associated with our request here anymore.
So again I wanted you to see this I want you to run into this problem because a lot of people kind of
designed these put request routes on back and servers in different ways.
You're technically supposed to make sure that a put request is going to replace or update all properties
of a record which could potentially lead to deleting properties off a record on the API.
If you really want to just update some properties we're actually supposed to use a different type of
request called a patch request so that the Patrick Quest we're going to pass some properties inside
the body the request that are supposed to be updated on the API.
And with a patch request just those properties are going to be updated.
It's not essentially an overriding operation that's going to cause some properties to be dropped off.
So let's try updating our action creator to make a patch request as opposed to a puts.
So I going to go back over to my actual creator file to find at it Stream right here and essentially
all you have to do is rather than calling put right here to make a point type request we're going to
make a patch request instead.
That's it.
So now when we make a Patrick quest to our back in API with form values we're just going to be updating
the form values on our API and we're not going to destroy or unset any properties with our stream because
we were making the request before.
So let's flip back over to our application and we'll test this out really quickly.
Now this time I'm going to attempt to edit this Stream right here so click on edit and all change the
description of it.
I'll say this change was made by a patch request and then I will submit this.
Now inside my requests log right here you can see that I'm now making a patch request so I can select
that I see the response right here and the response has the new description as the same title.
It has my user ID.
Most importantly so I did not overwrite the user ID.
And now when I go back to a list of streams I still see the edit and delete buttons as I would expect
whenever I edit a stream.
Ok guess that's pretty much it.
Again I want you to see this issue because you're going to see a lot of conflicting API is where sometimes
if you make the request it's going to drop off some properties and in those cases you're supposed to
use patch instead.
But a lot of people choose to just kind of disregard this rule when they are designing API or back and
servers.
A lot of people just say oh yeah just make a put request in the back end server or we'll just merge
these different properties as opposed to dropping some off as we just saw.
I guess now that we've got this all fixed up let's take a quick pause right here and we'll continue
in the next video.