In the last video we finished wiring up our new middleware required credits to our app.
Post-rock handler right here.
So now inside of our request handler body we can start to put together some logic to create and save
a new survey to our database after we create the survey.
We can then start to think about how we're going to send out an email to all the different users who
are specified in the survey itself.
Now as we start to go through this process I'm going to tell you that this request handler right here
is going to very shortly grow to be quite large.
There's going to be a lot of logic that we're going to stuff into this request handler body.
So in this video we're going to start off by doing just a little bit of code just to get started just
to get our feet wet.
And then in the next section we're going to talk about what this request handler is really truly going
to do in all the different logic that we're going to stuff inside of it.
So this video is all about just kind of getting our feet wet just kind of putting our toes into the
pool that will then take a break and then talk about exactly how we're going to dive into the deep end
with this.
So to get started the first thing that I want to do is take the incoming request object right here.
Remember we've said several times that when someone wants to create a new survey we're going to expect
the body of the request to contain a couple of different properties.
So the body of the request should contain the title of the survey or like the title of the campaign
the subject line to use for the e-mail the text to show in the body of the e-mail.
And then a comma separated string of e-mail addresses to send the survey to.
And so you might notice that I updated this diagram just a little bit to be very explicit here.
So we're saying that the list of people to send the e-mail to is going to be a comma separated string
of e-mail addresses.
OK.
So I want to make sure that we can access all of these different properties out of the request body.
So it's going to be step number one after we make sure that we can request.
Or can I get a handle on all these different properties coming up the request.
We will use them to create a new instance of a survey using the mongoose model that we set up and just
like one or two videos ago.
So let's first make sure that we can pull all these different properties out of their requests body
back inside of our survey routes file.
I'm going to reference our rec object.
Remember Rock being short for request.
It's the object that represents the incoming request to our application.
Now recall that all of the information that gets passed along inside this request exists on the body
property of that object.
So to get access to all the different properties we're passed along with the request we can say wrapped
up body.
And then if we want to pull off all these different properties that were passed along we can do a little
bit of as 60 structuring.
So off the body property I want to get access to the title subject body and recipient's properties like
some OK.
So again at this point we do not have any logic on our front end that is specifically making requests
to this end point and including all of these different properties in the body of the request.
I'm saying that this is how we're going to design our back and server.
So we're going to design the back end server assuming that we're going to pass along properties and
we're going to make sure that when we move back to the re-acting redux side of our application we will
really make sure that when we pass off all these properties or when we create a new survey on the front
end we pass along all these different properties as well.
So this is not something that you know we're not saying that this is being done already.
We're just saying this is how we want this back and rout to be working.
Now I want to mention that sometimes when you start working from the back end first it feels kind of
like you're pulling a lot of design decisions out of thin air and sometimes it might feel like life
would be easier if you started on the front end.
However I've got to tell you that in reality for a lot of very serious very professional projects you
might work on.
It's a little bit more common to start off working on the back end server and saying OK here's the different
routes we're going to have.
Here are the different requirements of each handler and that's exactly what we've done so far with this
diagram right here.
So a little bit more common in the real world to do the back end design first even though it might feel
like the front end would be a little bit easier to start off with and it was just a little side topic
there.
OK.
So we've now got access to all these different properties.
I now want to use the survey mongoose model that we created just a little bit ago to create a new instance
of a survey.
So a record that will represent this survey being sent out to a bunch of users inside of our Mago database.
So remember that we created that model just a little bit ago.
Inside our models directory as these survey G-S file.
Now before we just require in this survey jazz file remember that we've got a slightly different methodology
of getting access to mongoose models because of one of those issues around running your tests with node
and mongoose.
Very much a side topic here.
Just recall that sometimes if you use mongoose with any type of testing framework it will sometimes
complain if you attempt to require in a model file multiple times.
So just to kind of skirt that issue just to get around it at the top of this file We're going to require
in mongoose and then to get access to the mongoose modeled class that we'd previously created which
we had called surveys will say Konst survey survey is mongoose model.
When we pass in a string with the name of the model that we had assigned to which was surveys.
So again we could certainly require directly out of the survey file right here.
Our mongoose model class we're just taking this slightly different approach to sidestep that issue around
running tests that you might run into at some point in the future if you had tested this project.
OK.
So we've now got the mongoose model class.
Remember that we can use the model class to create an instance of a survey an instance of a survey is
not automatically persisted to our Mongo database.
We just first create the survey.
We can kind of play around with it a little bit and actually save it to the database.
We have to eventually call the Save function on it.
So right now we're going to take these properties that we've got access to from the request body and
we're going to use them to create a new instance of a survey.
So we'll say Konst survey and notice that we're using a lower case survey here to indicate this is an
instance of a survey.
This will be a new survey and we pass in all the different properties that we want to assign to this
new record.
So before we just kind of dive in if you recall our surveys we've said have a title a body a subject
and a list of recipients right here.
And we have said very importantly that the list of recipients was going to be a sub document collection.
So I think that the first couple of properties will be pretty easy and pretty straightforward to set
up.
But we're going to take a quick pause when we get down to the sub document collection right here and
just reiterate exactly how some document collections work.
Make sure we're on the same page there.
Okay.
So back over inside of our survey route's file We're going to take that title and assign it to our new
survey.
Now immediately you will see that the key and the value here are identical.
So we can use a little bit of E6 syntax to condense down to be just Tida like so now we can do the same
thing with the subject and the body as well.
So subject and body now recipients.
So this one's going to be a little bit more interesting.
Remember in our survey schema we had said that the list of recipients was going to be a sub document
collection that uses the recipient schema.
So let's go and glance at the recipient schema really quick just get a reminder of what's going on inside
that schema.
So we had said that every single recipient would have an e-mail property and would have this respondent
property which was going to be a boolean that defaulted to be false.
So really when we think about creating a new recipient we don't have to assign or specifically indicate
what the responded property is it will be automatically defaulted to false for us whenever we create
a new recipient.
So all we really have to care about is making sure that we specify the e-mail as a string OK.
Now creating the subdominant schema here is going to be just a little bit complicated.
So I think that maybe you would be best if we take a quick break and we come back in the next section
and have a nice diagram to look at to understand exactly how we assign the list of recipients here.
So let's do that.
Let's take a break.
We'll come back and we will talk about exactly how we create this document collection.
So I'll see you in just a minute.