Editing the Active Organization

In This Lesson

We'll make use of our useResourceActions composable to add the ability for our user's to edit their active organization.

Created by: @tomgobich
Published: 1 year ago

Join the Discussion 2 comments

@memsbdm
1 year ago

In the file inertia/composables/resource_action.ts, this line const form = useForm(defaultForm) is giving me the error ts: Argument of type 'Form' is not assignable to parameter of type 'FormDataType | (() => FormDataType)'. Type 'object' is not assignable to type 'FormDataType | (() => FormDataType)'.

As I did not find the FormDataType in inertia exports I replaced <Form extends object> with <Form extends Record<string, any>>
I don't know yet if it is going to create any trouble later but it might help for this lesson.

1
1. Responding to memsbdm
  
  @tomgobich
  1 year ago
  
  Hi memsbdm!
  It looks like this was a tiny change that occurred between InertiaJS v1 and v2! In this lesson, I'm still working with Inertia v1, which is why everything works without issue for me. We upgrade to InertiaJS v2 in module 13, though this is one change I missed!
  Here's what the FormDataType looks like in InertiaJS v1:
  And then here is what it is now in InertiaJS v2:
  So, your solution is perfect for v2! You could probably try and use `Record<string, FormDataConvertible> if you'd prefer to be as accurate as possible! Though I don't believe what you have should cause any issues down the road! Thank you for sharing! 😊
  
  1

Transcript

in the option to edit the organization. So we'll do drop down menu item, add the text edit, and then we can provide in the organization's
name to say edit and then whatever the organization name is. Now for the click handler, we're going to want to reach for our dialog open again.
So we can do at click equals dialog open. But now since we're editing, we're going to want to provide in the resource, which is
our organization, and then update the default state of the form with values for that resource,
which for our organization is only going to be the name, and we can set that value to the organization's name there.
What this will do is overwrite the default value of our form's name here with the actual organization's name.
Remember, we set this to where the open updates the form's defaults. So this line here overwrites the default form name, which is an empty string with the actual
organization's name, ensuring that whenever we open up the edit dialog, it's populated with the organization's actual values.
Then we're resetting the form to commit that change to the actual form states. The next thing that we're going to want to do is scroll back down.
We need to update our form dialog to indicate that we are actually editing when we are indeed editing a record. If we remind ourselves of what this looks like real quick, jump into our form dialog
here. We have this editing boolean, and inside of here, really all that this does is just make text updates to indicate that we are editing and that we are updating inside of our button.
So we'll want to provide that flag into our organization select, and we can use our dialog's resource to indicate that. When we're creating, we don't provide a resource in, and when we're editing, we do provide
a resource in, which is set to our organization's data. So we'll set editing equal to dialog.resource, and then we can optionally chain in that ID
so that if resource is populated, it will provide in this ID, which will be a truthy value. And if resource is not populated, it will pass in null, which is a falsy value.
The last thing that we need to do is handle the submission of this form, because currently if we scroll up, we're just posting to our creation endpoint. There's a couple of options with what we can do here.
First, you can check whether or not an ID is populated, again, via dialog, value, resource, and then optionally chain in the ID.
If we have an ID, then we know we want to update, otherwise we want to create. So that's one approach that you can take with it.
An alternative that you may prefer instead is we can jump back into our form dialog and have this determine which emit to do, depending on whether it's editing or not.
So if we are editing, we could emit something like update, otherwise we could emit something like create, and then of course we need to update our emits to update and create as well
if we go with this approach. With this, if we jump back into our organization select, what we would be able to do is let's
just grab a copy of that form submission right there, we can get rid of our on submit altogether,
scroll back down to our form dialog, replace submit with create, and then on create, do our form post to our creation route.
Otherwise we could do at update to form put, and we need slash organizations slash ID to post to the update route, and then we can also pass in our on success handler there
as well. Sorry, that should be organization ID. So you have those two different approaches that you could take for handling whether or
not you're creating or updating and submitting to the correct endpoint. Now I don't believe we've actually created our update endpoint yet, but real quick, let's jump into our browser and just make sure that everything looks okay.
So let's open up our organization dialog, click edit testing, and you'll see that we're populated now with that organization's name as the default value for this form.
If we jump back into add organization, it's back to an empty string. So that's what's happening by passing this data in as the second argument to our dialog
open. Now let's go ahead and rig up our update route. So let's start by jumping into our routes web.
We can add in a new router, put slash organization slash ID, and use the organization controller,
and we should have an update method inside of there as organizations updates. All right, let's go ahead and command click into that controller, scroll down to our updates
right here. I don't think we need edit or show, so we can go ahead and get rid of those methods. And in addition to params and requests, we also want the auth user, so we'll grab that too.
And the first thing that we're going to want to do is validate our data. So we'll await, request, validate using, and from our create, we should already have an organization validator that we can reuse.
Next, let's jump into our terminal and let's make an update organization action. Node, Ace, make action, update organization, and let's put this inside of our organizations
folder. So let's create that action, clear our terminal out, and close it away. I also have my browser open here in the background, we'll close that away for right now too.
All right, we'll await, update organization, import that, call the handle method, and we're going to want to pass in the user, so we can reach for auth user and assert that.
We'll pass in the organization's ID from params.id, and then we also want to pass in that validated data. Then after we've updated, we can return, we also need our response, so let's grab that
as well, and we'll return response redirect right back to where they were. All right, let's command click into the handle method of our update organization, fill out
our params, so user of type user, ID of type number, and then we'll infer using bind.js the type of our organization validator.
All right, let's extract all three of those out of our params, so user, ID, and data. First we're going to want to get the organization that we are updating, so we can do that via
await user, reach for the organization relationship, and query where the organization's ID is the ID being passed in.
We can call first or fail to either find that first organization or throw a 404 error. Again, as mentioned previously, we're using organizations.id here because this many-to-many
relationship will need to join in our organization's users, and through that, we're going to have multiple ID columns within that query, so we need to identify which table it is we want
to assert the ID for here. Once we have our organization, we just need to await organization, merge in the updated data, and then call save to commit that change to the database.
Then we can merely return back the organization in case whatever calls this action needs it as well. That should complete our flow, so if we jump back into our browser now, let's jump into
our dropdown, edit testing use resource actions, and let's just try to tack on edit to here, and we can click on update to make that change, and you'll see it's immediately reflected
here inside of our dropdown button. If we open up our dropdown, there it is. It didn't create another record, it just updated the existing one.
If we come back and edit, and we get rid of that updated text, just like so, it's right back to how it was now.
Furthermore, if we come back into add, say here is another test, add that one, now we're at here is another test.
It created one successfully, it didn't update any pre-existing one, so everything there seems to be working a-okay too.

Building with AdonisJS & Inertia

91 Lessons

14h 3m

Getting Started

The Basics

Working with Forms

Database & Project Scaffolding

Authentication & Onboarding

The User's Organizations

Difficulties, Statuses, & Access Levels

Courses

Modules & Lessons

Settings

Organization Members

Authorization

InertiaJS 2

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.