All right my friends this is it.
The last section the last big feature were at the very end of the application.
I know it's been a very long course but remember we have covered a tremendous amount of ground.
So I'm really excited to finish this thing up.
The last feature that we have to work on is thankfully also one of the easiest in the entire application.
So really the last big thing that we have to do is make sure that whenever a user goes to the dashboard
component we show them a list of all the different surveys that they have created.
So basically whenever the user goes to the dashboard we need to make a request to our back end API to
get all of the different surveys that the current user has created.
And so that's that last part is very important.
So here's our survey routes that we had been planning out all this time.
So we're going to put together this route Whenever someone makes a request to API slash surveys we want
to return the list of surveys created specifically by the current user.
Not all the surveys just the ones that have been created by the current user.
So we're going to first tackle this on the back end of our application.
We'll make sure that we can produce a list of surveys and then once we have the back end working we'll
then flip on over the front end and integrate all this stuff into the react and redux sides of her application.
Now even though I've said that this is the easiest feature in the course there still is a kind of interesting
Odan and or two of you know a little little bit of interesting challenges in here somewhat.
So let's make sure we still stay on our toes and finished nice and strong.
OK.
So let's get started right now.
No need to take a break or anything.
So the first thing we're going to do is create a new route handler to respond to any GET request made
to API slash surveys.
So given that this is some route having to do with surveys I think that we should go back into our route's
directory and find the survey route's file.
And I think this would be inappropriate location to add this last route handler.
So inside of our module exports function right here we're going to add in another route definition.
So we'll save anyone makes a get type requests to API slash surveys then respond with all of the surveys
created by the current user.
There you go.
OK.
So reading this actual query to reach into our database and fetch out all the different surveys really
won't be that bad but there's going to be one or two things along the way where we just need to be kind
of cognisant of the amount of data that we're loading and sending back to our user.
So we're going to first start off by taking a somewhat naive approach.
All right we're going to do this the easiest most straightforward way possible.
And then once we implement it we'll kind of see that we might run into a difficulty or two in the future.
And so we'll come back to this route handler and do a little refactor to it.
Now the Reflektor we're going to do is very very small.
So don't don't be sitting there thinking that we're going to write some really awful code.
We're going to write totally fine code.
Just going to point one thing out after we're all done with everything.
OK.
So we're going to write a query here that will reach into our surveys collection inside of Mongo TV
and pull out all the different surveys that have been created by the current user.
So before we write out the actual query just a couple of quick reminders.
First off recall that the current user is available on the wreck object right here as rec dot user.
So we want to figure out who the current user is just reference red user.
Secondly to figure out which surveys a user created we had previously when we put together the survey
model we had said that every survey would have this underscore user property right here.
And we said that this underscore user property would contain the ID of the user who had created a particular
survey.
So essentially to make sure that we only pull out the surveys that belong to a particular user We will
ask mongoose to fetch all of our surveys where underscore ID is equal to the current user's ID.
So let's go back to our survey route's file and write out the actual logic for for this.
I think it's going look something like Survey dot find and so find will look into our collection of
surveys and it will do a search and pull out all of the different records that meet some specific criteria
and that criteria will be provided in the first argument to this query which is going to be an object.
So we're going to say find all the surveys that have an underscore user property equal to rec user id
like so OK.
So this is pretty much the query.
Just that simple.
Not that bad right.
Now one thing to keep in mind because remember there are still a couple of things we need to be on our
toes about reaching out to the database.
Asynchronous requests whenever we have asynchronous code we are making use of the async awaits helpers.
So I'm going to say this list of surveys will be assigned to the variable surveys and because this is
an asynchronous query we're going to market with the wait keyword and then because this function now
contains an awaits reference or a wait key word will make sure that we mark the function as being a
sync as well like so.
OK.
Now one other quick thing that we can very quickly fix in here as well and I'm just planning towards
the feature future excuse me and thinking about all the different aspects of our application.
Looking at the code inside this request handler it's clear that if someone is going to make requests
to this API we really expect them to be logged in because we're referencing rechts user ID right here.
So clearly if you want to to access this handler we want the person making the request to be authenticated.
So we're going to reuse that require a log in Middleware that we put together way long ago to ensure
that a user is authenticated.
So remember how we wire up this middleware right here.
We pass them the middleware as the second argument to our request handler.
So after we specify the route we'll then say require log in put our comma in.
So essentially whenever someone makes a request to this we make sure they're authenticated and then
they can go off to the request body right here.
OK.
So now the very last thing that we want to take care of we want to make sure that after we have the
list of surveys we then send a response back to whoever made this request and say hey here you go here's
your list of surveys.
So pretty straightforward we'll just say residents send surveys like so OK.
So this this co-direct here is definitely going to work for our purposes.
But there's one kind of loose end here that I want to remind you about.
Remember that when we were just putting together our web hook and point right here we made a huge deal
around this query around the fact that it did not have to load up the big list of recipients because
that list of recipients can be tens of records long it can be hundreds of thousands actually tens of
thousands records long.
And so you can very quickly imagine inside of our new API slash cerveza handler if a given user has
like 50 surveys and every survey has 10000 or 15000 recipients.
Clearly we do not want to pull out all that information from our back end and send it down to our user.
Any single response.
And if you really think about it at all looking back at our markup for this feature the mockup itself
doesn't really have any indication that we care about the individual recipient email addresses like
there's clearly no reason to really send back the entire big list of recipients.
So I think that when we pull out our list of surveys from our database we want to somehow tell mongoose
and tell Mongo that when we get some response back from this query we do not want to also receive the
big long list of recipients for every individual survey.
Now we could certainly leave our code as is right now because as you and I are building this thing we
never really have more than like you know five different e-mails associated with every survey.
So in theory right now we definitely believe our code like this and be totally happy with it.
But again I'm kind of thinking to the future and I'm thinking about when people start really heavily
using our application.
We don't want to accidentally ship down like tens of megabytes of data inside a simple request handler
like this one right here.
So let's take a quick break.
When we come back we're going to figure out how we can tell mongoose and Mongo that when it finds our
list of surveys we do not want to get the list of recipients inside of each survey.
So let's take a quick break and tackle that challenge in the next section.