Storing Lesson Order Changes & Handling Cross-Module Drag & Drops

In This Lesson

Save the changes made to lessons inside a course when a user uses drag-and-drop to move a lesson. Users can change the lesson order inside a single module or move a lesson into a new module, so we'll need to handle both use cases.

Created by: @tomgobich
Published: 1 year ago

Join the Discussion 0 comments

Be the first to comment!

Transcript

And this behavior is made possible thanks to Vue Draggable's grouping behavior. We've assigned a modules group to all of our modules, meaning that we can move any module between the module group.
And we've added lessons to a specific lessons group throughout those modules, again, meaning that we can take any lesson and move it to any other lessons group there as well.
So as we move our third lesson from our first module to our third module, we want to update not only the ordering inside of that third module for the lessons, but also inside of our first module for its lessons as well, while at the same time updating the module for that third lesson from first to third.
So it's just kind of added in a whole layer of complexity to the situation.
And on our client side, since this involves changing modules, we want to have this outside of our sortable lessons component inside of our sortable modules component so that we can have access to the new lessons, its new modules and the modules new lessons ordering.
So inside of our sortable modules, we'll add in a new function just below our onModuleOrderChange called onLessonOrderChange. And we want to use our modules as the starting point.
So we do const data equals modules value and we can map over each module in that array.
We want to return back a new object containing the modules ID as well as the lesson IDs that are now bound to that module.
So we can get access to that via module.lessons and we can map over those each individual lesson to grab the specific lesson ID.
So we'll have an array of objects where the object contains the modules ID and an array of IDs for our lessons.
Before we move on to adding that validation, though, we want to scroll down to our sortable lessons as we're going to need to bubble up the at end event from inside of here out into our sortable modules.
So we'll add an at end event handler that we'll call our onLessonOrderChange event. And then we'll dive into our sortable lessons component so that we can bubble that upward.
On our sortable component, just like we did with our modules, we want to then add that at end handler. And we're going to want to emit that end event up to the parent.
And it looks like we don't have that defined in our emits. So we'll scroll up to there and add end to that. That should do it for our client side. So we can scroll on up to our lesson validators.
And after our patch, let's add in an additional one.
So export const lesson order validator equals bind compile and then bind object adding the modules key to it.
We'll have an array of modules and inside of this array is going to be an object. Each object contains the modules ID.
So this is going to be a bind number. And in addition to the modules ID, we're going to have an array of the lessons IDs as well. So we'll have a bind array that is also a type bind number.
Again, just like with our module order validator, with how we're going to be reordering these inside of our actions, we don't really need to worry about whether or not it exists in our organization here,
as we're going to be re querying them and using the query values as our source of truth. And then if we're reordering something, we're going to have at least one item in that array.
So we don't need to worry about making any of these items optional in our validator. So we can give it a save and move on now to our lessons.
And we haven't made it yet. So let's dive into our terminal next and do node ace. Make action lessons update lesson order and create that action.
Clear that out. Jumping back into our text editor and now into our new update lesson order validator.
For our params, we're going to want our organization of type organization, our course ID of type number,
and then our data, which we can infer from our lesson order validator. We're going to be using that validators type in a few spots.
So I'm going to go ahead and plop that into a new type just called sort data. So infer type of lesson order validator.
And then we can assign that type sort data to our rams data. And we can go ahead and extract all of those out into our handle method.
Very first, let's grab our course. So we'll await organization related courses query where the ID matches our course ID.
And then find the first or fail. First check number one, making sure that the course that we're working with actually exists in the organization. Next, we want to grab our lessons. Set that equal to await using our course.
And it has many through relationship to our lessons. Querying them all and selecting specifically their ID, module ID, and their order.
We're using our course to grab all of our lessons for the course so that we have a flat list of our lessons directly to work with. In addition to that, our lessons might have changed modules,
which could make finding a lesson a little bit more difficult going off of our data.
This is also check number two, making sure that all of the lessons that we're working with exist inside of the course that we're working with as well.
Our next task is to take our sort data, which is an array of modules with nested arrays of lessons inside of them,
and flatten it all into a flat array so that we just have a single array of lessons and then the modules that those lessons are bound to to work with.
We're going to add in a new static private method called flatten data that takes that data in, which is a type sort data.
We can return data and then reduce over our modules to end up with a flat array of lessons data.
So we'll be looping over each module to do that, starting with an empty array as our initial data.
Now we need to provide a type for that initial data so that we know what type it is that we're working with here. So we'll create a new type up here at the top of our file called lesson lat data.
And this will have an ID of type number, a module ID of type number, and then an order type number as well. And then we'll assign that type to our reducer.
So lesson lat data, just like so. And that's going to provide a type here for our initial array here as well.
So ultimately, what we want to do is as we're reducing over our modules and essentially looping over each module to get a module instance,
we want to take that modules lessons and flatten it up and then return it back, merging it with the final lessons array.
So we'll grab the modules lessons by looping over the module dot lessons using a map.
And the lessons array off of our module is an array of lesson IDs.
So we can give this a name of ID and then grab the index so that we know what the lessons order is inside of the actual module that we're looping over.
Then we'll return back a new object with that lessons ID. The modules ID that we're currently looping over, which will be the module dot ID.
And then the order, which will be the index inside of our module lessons array. That makes up our lesson flat data that we're ultimately after.
So we just need to merge that in with our final lessons array and send it on back from a reducer.
So we'll spread in our lessons and then spread in the modules lessons to the end of that.
You want to add the modules lessons after the lessons to keep the sort intact with the module data and its lessons data.
Give it a save to see whether or not the squigglies are due to formatting and they are not. So let's see what this one is. Type lesson flat data must have a symbol iterator method that returns an iterator.
Ah, yes, we're working with an array of lesson flat data. So we need to set that there to an array for our reducer type. OK, so now we need to make use of this flat data method.
So we'll do const lessons data equals this flattened data, passing our data into that. Then, just like we did with our modules, if anything here with our update fails,
we don't want to save anything as that could result in mixed and matched data at the end of the day.
So we can go ahead and await and import DB from Lucid Services DB and get ourselves a transaction going, providing in a managed transaction callback.
We're going to loop over our lessons data as it's a flat array of all of our updated values
and then find its applicable lesson inside of our lessons array to use as our actual update object. We don't need to do this sequentially. We really didn't need to do our module sequentially either,
but it's a little bit more impactful here as we have more nested data that we're working with and we're more likely to have a lot more lessons than we do modules.
So let's get ourselves an array of update promises going and we can get that by looping over our lessons data using a map.
Inside of this map, we'll extract out the ID, module ID, and order from our lessons flat data object and then start our callback.
Inside of our callback, the very first thing that we want to do is find the applicable lesson model object for the data item that we're looping over.
So we'll do that as const lesson equals lessons.find and we'll call this item so that we're not reusing the lessons variable.
And we want to find the item where the ID is equal to the lessons data ID that we're looping over. Then we can have this lesson use our transaction
and then return lesson merge in the module ID in its updated order and then save that to the database.
So if our lessons data has changed a lessons module, we'll pick that up by merging in the module ID right there
and then we're also updating the order at the same time by passing order into that merge call as well. Now we can make this a little cleaner on ourselves by doing a check to first see whether or not we found a lesson match
and if we did find a lesson match, we can check and see whether or not we need to save anything at all. So if this lessons data didn't change, if the module in order is the exact same,
we don't need to send anything to the database as nothing's changed for that lesson. So we can just skip it inside of our array rather than sending an additional call to the database.
So let's add a variable called is same that checks to see whether or not the found lesson, if we found one, has an order that matches the order that would be updated for it
and whether or not it has a module ID that matches what its updated module ID would be.
So essentially checking to see whether or not the merge data would change anything for this lesson.
If we don't have a lesson or that lessons data is the exact same as what would be updated with this loop,
then we go ahead and just return out of the callback, skipping this item and leaving it alone. Then we need to await for our promises to resolve before ending out our transaction.
So outside of our lessons data map, where we have our promises array, we want to return promise.all and then pass our promises in.
The resolved value of our promises is going to be our lesson model object or undefined if we ended up bailing out of that loop item.
By returning that promise.all back from our managed transaction callback, our managed transaction will return that same value as well.
Whatever you return from the callback of a managed transaction, it will return in favor. So we can return back the exact same data that we have in our promises here just by simply returning back the result of our DB transaction,
thus in turn ending out our update lesson order action here. So as a quick recap, before we move on to defining the route definition here,
our sort data comes through as our lesson order validator, which contains an array of modules, each having a module ID and an array of lesson IDs inside of it
with the updated sort of a module's lessons inside of it. We then line all of that data up with our lesson flat data object,
just caring about the ID of the lesson, the updated module ID for the lesson, and the updated order for the lesson as well. We do two checks.
First, that the course that we're wanting to work with actually exists inside of the organization and that all of the lessons that we're wanting to update exist inside of that course.
If any lesson IDs get patched up with our payload that don't exist in this course, we won't find it in our array here and we'll ultimately just end up skipping over it
and not saving anything to the database for it. We then start our transaction so that we ensure all of our updates succeed
or none of our updates succeed, and then loop over our flat list of updated data, finding that lesson, checking then to see whether or not anything's changed for that lesson.
If nothing has changed, then we don't worry about it and return back, moving on to the next loop item. If that lesson has changed, then we go ahead and tell it to use our transaction
to merge in the updated data and save that to the database. I'm getting rid of those question marks here because we have the check right here to see whether or not we have a lesson, meaning that those are no longer potentially undefined.
We then take the end results of all of these promises that we're returning back from our save into our promises array, ensuring that they all resolve inside of our managed transaction
and then return the result back from that managed transaction, which in turn returns it back as well. So that is the whole flow there.
Let's next jump into our lesson controller so that we can add a method for this. So we'll put this right underneath our tag as async, order, and we'll need our params,
request, response, and organization from our HTTP context.
First, validating our data using await, request, validate using, lesson, order, validator.
Then we can await, update, lesson, order, import that action, and call its handle method passing in the course ID as params.courseID,
the organization, and then the validated data. At the end of the day, we'll return, response, redirect, and send the user right on back where the request came from,
taking us then into our web routes. And this route definition is going to be a different URL structure than our other lesson routes as we need the course ID along with it.
So we'll send a router patch to slash, and since we need a course ID, we'll prefix this with slash courses, slash,
and then we'll have that course ID, slash, lessons, slash, order, and tell it to use our lessons controllers order method as lessons order.
I'm not entirely sure whether or not when we added this on the front end, if I included the course ID. So I'm going to scroll back down to the sortable modules here and scroll back up to our script.
And, oh, look at that, we never finished our thought here. I had a feeling that something was missing with this. Okay, so we want to send this using InertiaJS's router as a patch request
to, and we can use our prefix URL for this as well, since it starts with slash courses and then our course ID,
and then do slash, lessons, slash, order, providing our payload data here with a key of modules into that patch request.
And then just like we did with our order update for our modules, we want to preserve the scroll position, so we'll set that to true.
We can't call our data here modules because we already have modules used elsewhere inside of our script. So we'll call it data here and then rename it to modules for that patch request
so that it matches our validator's expected key. Okay, now that we have everything set, we should be able to jump back into our browser. We saw that do its refresh there.
And let's try moving our third lesson to first in our first. And, oh, shoot, did I do the exact same thing that I did in the last lesson? I sure did.
Okay, we need value on that prefix URL. Sorry about that. And jump back into here, undo that. Let's refresh. There we go. Okay, let's try that again.
Let's take our third lesson and move it up to first inside of our first module. And whenever I drop that, you saw that the lesson ordering actually updated,
meaning that it went out to our server and it came back with its updated ordering. So our third item went from 3.1 to now 3.0 and first went from 3.0 to now 3.1.
If I now take that third and move it over into the third module, drop it there, you see first in our first module went from 3.1 to now 3.0.
Fourth went from 3.2 to 3.1. And third is now 2.0 rather than 3.0. If we give our page a refresh, all of those orderings persist,
meaning that this is actually saved inside of our database as such. We can then take fourth, move it up to our second module, and everything there updates accordingly.
You can also see that the ordering count for the number of lessons inside of a module updated there as well. So everything seems to be working okay thus far.

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.