Current section: Mutations 7 exercises

Leveraging Name and Value in Buttons for Multiple Form Submissions


00:00 So the first thing that we're going to do is something that not a lot of people really know about but that is that you can specify a name and a value on a button and That will be serialized as if it were an input and what's really interesting about this is if we had multiple buttons you can have a different name and intent and

00:20 You could say favorite and here. Let's just do No variant there boom favorite So now we have a favorite button and based on the name and intent or the the name and value of the button That's clicked. That's what will be submitted when it actually is ultimately submitted

00:37 So that's pretty cool because it means that you can have multiple submit buttons You can have one that says update or you can have one that says delete or you know, whatever So with that name and value and of course you could have multiple forms as well They don't all have to be in the same form

00:54 But with this name and value we can distinguish between the different types of submissions that could happen here So let's get our form data. That should be familiar a weight and then that's going to be request request form data and then we're going to get the intent from the form data and

01:12 Then we're going to do a little bit of checking here if the intent is not equal to delete So that's the intent that we specified right down here So if that's not the value, this is the only thing you can do here So let's just throw a new response that says hey bad request status 400

01:32 Right, and this might actually look kind of familiar we've we've got a utility for this called invariant response and so we'll say bad request there and On top of that we can get rid of this status because that's the default behavior for our invariant response As I said, it's pretty common. So with that

01:50 Now we can make sure that we can distinguish between different intents now Normally, this is not the way that you would do this, right? Because if you add the intent behavior, then you're probably going to have multiple different kinds of intents And so what I typically find myself doing more often is I will add a switch statement to say intent and then we can say

02:12 The delete and then here's our logic for delete. In fact, let's just do that right now We'll move all this up here Get rid of the break because we got a return and then in the default case we can add this invariant response Or it doesn't actually make a whole lot of sense to have this invariant response here

02:30 So what we'll just do here is we'll throw a new response and Invalid intent and you could also add what the intent was if you want to do do it that way But yeah, I find myself doing this my switch

02:48 Cases don't typically get very long and you can absolutely just use regular JavaScript stuff that you would do to say Okay Here's here's my code for what this thing is doing and here's the code for what this thing is doing and when we get to Forms and adding more complex logic and things in the future

03:05 Then you will see a couple of places and you will actually implement a couple places Where we follow this type of pattern and it works out really nicely for us There are also other utilities that allow you to make like named actions and stuff like that But I find that switching on an intent like this works actually quite well, and that's what I've been doing

03:26 so If you need to have multiple form submissions or form actions on a single page then using the intent Approach by specifying a name intent and a value of delete works quite nicely I should also mention that the name intent is not super important

03:43 This can be whatever and as long as you're accessing the same thing, then it will work just fine But I find that intent communicates my intent. So that's what we're going to do and That is how you do multiple form submissions on a single route