Patching Tag Changes for our Modules & Lessons

In This Lesson

We’ll incorporate our Tag Selector component into our modules and lessons to facilitate easy visibility and updates of their statuses and access levels.

Created by: @tomgobich
Published: 1 year ago

Join the Discussion 0 comments

Be the first to comment!

Transcript

Our modules are going to have just the status and our lessons are going to have a status and access level. So we can start by jumping into our terminal because we're going to need two actions for this.
So we'll do node Ace, make action. We'll need one for our modules. We can call this our update module tag, and then we'll need one for our lessons as well.
So we'll make another action inside of our lessons folder called update lesson tag. We can go ahead and clear that out and jump now into our text editor.
Before we dive into those actions, we're going to need to add in some validations. So we'll start with our module again, export const. And however you name this is completely up to you.
I'm going to call this our module patch tag validator. And we'll set this to vine with metadata and we can pass in our organization metadata type.
Then we'll want our compile and to that we can provide a vine object. As I stated a moment ago, our modules only have a status ID that we need to worry about.
We'll set this to type vine number and we need to verify that it exists in our organization. So we'll import that helper and this will be checking against our statuses table.
This is the one and only key that we'll be patching up for our modules tag system. So we're going to make it required here by omitting the optional flag on it.
We can go ahead and give this a copy and jump now over into our lesson validator and paste it in. Switching this from our module patch tag validator to our lesson patch tag validator.
It too is going to require our organization metadata as we still want to verify that it exists in our organization.
Unlike our module, in addition to our statuses, this one also has an access level ID that we need to validate against as well.
And for that, we'll use our access levels table to verify its existence in our organization. When we change a value with our tag system, it's only going to be patching one or the other keys.
But we want to verify that at least one key is being provided in that patch request for update. So we can add on to each of these an optional chain to make the field itself optional.
But we can use the require if missing rule to require the field if the other is missing.
So to this, we'll provide in our access level ID and then we can give the optional require if missing a copy and paste it on our access level.
Switching the required key to our status ID. I'm going to give this a save so it formats and then we'll walk through what we have here.
So inside of our browser, as we send up one of these changes, it's only going to impact our status or our access level, depending on what it is that we have dropped down here.
If I change our core status to planned from recorded, that's just patching up the status ID. We want that exact same behavior for our modules and lessons here as well.
But at the same time, we want to require at least one key to be sent up. So we're making each one of these two optional.
If the status ID is not patched up with the request, then that makes the access level required thanks to this required if missing rule. The same works vice versa for our status ID.
If the access level ID is missing from the request, that makes our status ID required again, thanks to that required if missing rule. With our validation set, we can scroll on up now to our actions.
We'll start with our modules. From our programs, we're going to need our organization of type organization, our ID of the module of type number,
and then the data for the request, which we can infer the type of from our module patch tag validator. Go ahead and extract those out of our handle method.
And our first task is to grab our module.
So the const module equals awaits organization related modules query where the ID is the specific module ID that we're looking for and then call first or fail.
Then we just want to await module merge that updated data and then save it to our database. We can go ahead and then return that module back in case it's needed.
Do the exact same thing here for our lesson tag update action.
Again, we need our organization of type organization, the ID for the lesson, and then again, our validated data, this time inferring from the type of our lesson patch tag validator,
extracting those out of our handle method, grabbing our lesson.
So we'll await organization related lessons query where the ID matches the specific lesson ID, and then go ahead and call first or fail.
Await lesson, merge in the validated data, save it to the database, and then return the lesson on back. That then takes us into our controllers. Again, we'll start with our module.
After our update, but before our destroy, we'll go ahead and add in an async tag method.
That takes in our params, request, response, and organization from the HTTP context, first validating our data.
So we'll await, request, validate using module patch tag validator with organization metadata, providing the organization ID in.
Then we'll await update module tag, call the handle method for that action, providing the ID from our params ID, the organization, as well as the validated data.
We can then go ahead and return, response, redirect, and send the user right back where they came from.
We can go ahead and give this tag method here a copy and jump over to our lessons controller, pasting it in after our update method. And the only thing that we should need to change here is our validator.
So we want to use our lesson patch tag validator and then the action name. So this will be our updates lesson tag action. Give that a save. And now we can jump into our web routes.
And I'm going to put this after our put route definition. So we'll do a patch for this one as it's only updating a single key, or that's what it's meant to do anyway.
And then for our modules, we'll go ahead and stick with the same naming convention that may have going on so far for our other module routes using the course ID, modules, and then the modules ID, making this specific to our tags by adding in a slash tags to the end of that.
We don't need our course ID for this one, but we'll go ahead and keep everything consistent here with the URL. Then this will use our modules controller.
It's tag method as modules dot tags. Then we can jump down to our lessons.
I'm going to put this after the put again router patch slash lessons slash ID slash tags using the lessons controller tags method as lessons tags.
We can give that a save and then we need to add that actual tag component into our page. So we'll start with our sortable modules.
This will go just before our dropdown menu with that ellipse that we have. And we just need to use our tag selector component, self close it.
And for the props, we'll pass in a view model of our module status ID. We need the dropdown options, which will come from our organization statuses.
And then we need to discern where this should patch to whenever it is changed using the path.
And we'll do backticks and add in our prefix URL to start slash modules slash and we need our module ID slash tags.
And the specific key that we'll be updating here is our status ID key. Give that a save. Let's go ahead and jump into our browser real quick just to make sure that that's rendering OK.
Sure enough, here it is right there. We can go ahead and try to change it. So we'll switch from not started to planned, give our page a refresh. And sure enough, it persisted A-OK. Go ahead and fully test it here.
Jump into our edit, switch it now to recorded and it should automatically update there, which it does.
Awesome. Jump back now into our text editor over into our sortable lessons and do the exact same thing for our lessons.
For this one, we're going to put the access level selector first so that we maintain the status in the same vertical position as our modules inside of our list.
So for our access levels, we'll want our view model to be our lesson access level ID. The options will then come from our organization access levels.
And this will patch out to a path tactics slash lessons slash lesson ID slash tags using the key access level ID.
Again, the path is the URL that the patch request is going to send out to. And then the key is the actual object key that will send up with the form request.
So we want that to match the view model key that we're reading from here so that that updates accordingly. Then we need to add in our tag selector for our status.
So view model equals lesson status ID.
The options will be our organization statuses and the patch request for this one will go out to the path and the path is going to be the same lessons lesson ID slash tags.
This time, the key, though, will be our status ID and that should do it.
So if we jump back into our browser now, we should see our access level here on the left hand side and our status here on the right hand side.
If we change our fourth item to paid and switch that to recorded, give it a refresh. That persists A-OK for both.
If we jump into our third, switch it to paid in our edit field and switch its status to done, update that lesson. It updates A-OK that way there as well.

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.