-
- Now for our modules here, there's not really a hard reason for why we need to have a get module,
-
getting a specific modules details endpoint for our API. If you create or update a module or even patch a modules tag, you're always gonna get back the updated module
-
with that response. And an individual module isn't really useful in the context of our applications purpose.
-
So let's go ahead and omit that from Hopscotch and then we'll also emit it from our resourceful route definitions as well. So it's gone out of Hopscotch,
-
let's jump back over into our text editor. The way that we can easily omit it from our resources definitions is by chaining off of the route definition for it, a call to accept.
-
This allows us to specify which methods within the resource should be skipped over. And we specify that using the resourceful naming convention. So again, that's index for getting a list,
-
store for creating, show for showing an individual resource item, update for updating and then destroy for deleting. If you ever forget that, you always have TypeScripts,
-
little pop up here with those types specifically annotated. So in order to omit the get an individual module route definition, that would be our show.
-
So we'll omit that and we also need to provide that in as an array of strings there. By providing just that, AdonisJS will now no longer register a route
-
for courses modules show. And we can confirm that by jumping back into our terminal and again, running node ace list routes. And you should notice that we have one less route
-
for our modules here. And it is that specific get route that we have omitted for our courses modules show. So perfect, jump back over into our text editor
-
because what we did not omit is our index method for getting a list of modules. That may still be useful. We also want to go ahead and remove the show method
-
from our controller as well. So getting a list of modules is still useful in the sense that maybe we want to query the modules and lessons individually from the courses information.
-
Maybe the user interfacing with our API wants to refresh their list intermittently or just get a fresh list after they've updated or something of the sort.
-
So what we can do here is go ahead and grab our params as we're gonna need the course ID that we wanna get a list of modules for. And then we also need the organization.
-
We need to authorize the token for reading with that organization. Next, we need to dive into our actions. So as we've previously seen, we have our get course action
-
that contains this get module sub call within it. This queries those modules and provides them back as a separate property with our course.
-
So what we can do instead is pluck this method out into its own action and then call that action from within our get course action here.
-
So I'm gonna go ahead and give this block here a copy and let's drill through to our modules action folder and let's create a new one called get modules. Now, rather than right clicking
-
and creating a new file here, alternatively, what we can do is jump into our terminal and do node ace make action as we have the Atticast action package installed,
-
put this inside of our modules folder and call it get modules. Hit run for that and that will create our get modules action within our modules folder.
-
Right here, I'm gonna go ahead and just paste the method that we had copied in over top of the handle method that's stubbed with our get modules action here.
-
And we want to switch this from no longer being a private method to instead being our handle method. I'm gonna get rid of the params type up there too.
-
And to simplify this argument set here a little bit so that we don't need the entire course to query the list of modules, let's instead switch this to just be the course ID of type number.
-
That means that we're no longer going to be querying the modules off of the specific course, but to make sure that we're not allowing our users to request a module list for a course not within their organization,
-
let's go ahead and also accept in the organization here as well. So just command dot, add import for that, and then swap our course with the organization
-
so that we're querying off of it. Then we want to filter down to just the specific course that we're after. So after we've done our related modules
-
and initialize the query builder for it, let's go ahead and add in a where for our course ID. That will limit the responses that we get back
-
to just the modules within that specific course and everything else will remain the exact same. We'll still get back our modules ordered by their order field
-
and the lessons ordered by their order field as well with the status and access level being preloaded as needed. Great. So back within our get course action then,
-
we can go ahead and get rid of this method as we've now extracted it into its own action and we'll replace this with get modules, call the handle method there,
-
and whoops, for consistency sake, we've been having these all except in objects. So let's go switch back to our get modules and update it to that.
-
So we'll do type params equals and let's do our organization there of type organization and then our course ID of type number there
-
and then switch this to extract those out. So organization and course ID params, just like so. Okay, perfect. So everything still works the exact same within our get modules,
-
but now we've normalized the call to our actions handle methods to be an object as we have going on everywhere else inside of our application. So we just need to pass in the organization there
-
as well as the course ID. I go ahead and drop those onto separate lines and move the course ID to first. And the course ID is just going to be the ID
-
being passed into this specific action. You'd also do course.ID if you wish, but they're both guaranteed to be the exact same because if this ID being passed into the action
-
cannot be found with this query, it's going to go ahead and fail with a 404. We can also remove the no longer used import for our course right up there. Perfect. Back within our modules controller,
-
we can now go ahead and just return our get modules action, call the handle method and pass our course ID in from our params.courseID
-
and then the organization like so. Let's give that a save, jump back over to Hopscotch. First, let's jump back into our courses,
-
get course method and make sure that this still works after we've refactored it. Perfect. So we get back our course and we get back the modules list still. So let's see here.
-
We get one, two and three modules since we have now created an additional one. And then within those modules, we also have our lessons. So great. That is indeed working.
-
Back now within our get modules, this should return back the same subset that we just saw within our courses,
-
get course call just containing the modules instead. So we should just get back the array of modules when we send this off to our course ID of one and then modules there.
-
So let's go and send that off. And that's exactly what we get back. Awesome. So we get back all of the lessons and modules specifically within our course with an ID of one.
-
We can confirm the counts there too. So we should get back three modules, which we see we do indeed.
