So let's tackle the problem of missing
error feedback on the
signup and log-in pages now, because at the moment,
of course, if we, for example,
try to sign up with an email address that exists already.
We do catch this problem.
We check for that on the service side.
But if the user tried to sign up with an email address that
exists already,
we just redirect back to sign up and we don't share any
feedback with the user. And in addition,
anything that was entered in those input fields will be lost
after redirecting.
And that's of course not a great user experience.
Now, throughout this course,
we learned how we can tackle this problem.
We can actually use sessions as a solution for this as well,
and not just use sessions for authentication,
but also for temporarily storing data like that user input
and error data.
Now, I will say that an alternative would be to not redirect
here, but to instead render the signup template here.
If we would do that instead of redirecting,
then we would not generate an extra request response cycle
because with redirecting, we do,
we tell the browser to please make another request.
And therefore we generate a new request and a new response.
If we directly render and return a template. So day of,
for some HTML code, we don't do that.
And in that rendered template,
we could then pre-populate the forum.
But the downside of doing that,
what beat that we rendered as template in response to a post
request, because I'm in a function here,
the signup function that will be triggered upon an incoming
post request.
And we typically don't want to return HTML as a response for
post requests,
because if the user would then press the reload button on
that loaded page that was served for a post request that
would in the end, bring up that ugly.
Pop-up asking the user,
if he or she wants to resubmit the post data and if the user
chooses, yes,
and now we're post request with potentially problematic or
erroneous data would be generated.
Therefore it is more common to instead redirect to a get
route as a response for a post request.
And that is where we lose the user input.
Normally that's now where sessions can help us because with
sessions, we can avoid this.
So we don't want to render a template here.
We want to redirect instead.
And I did talk about that early in the course already.
Of course, I just wanted to bring it back to your mind.
I guess that's the ideal is overall core section after all
so long story,
we now need to flash as it's called some data onto the
session it's called flashing because it will only be there
for the next request response cycle,
where we serve that sign up page with a get request.
That's where we want to redirect here.
After all and thereafter,
the data should be erased from the session.
Now we did learn how that works.
And just as before in this course,
I will create new utility methods that help us with debt in
a separate utility file in the util folder.
And I'll name the file session flash dot JS,
because that's what we'll do in there.
We'll handle flashing data onto the session.
And here I want to create two functions that help us flash
data to session function,
and then also a function for retrieving that flash to data.
I'll name it, get session data.
Of course the function names are up to you.
Now we'll populate those functions with more life in a
second for the moment,
I'll just export them grouped together in an object.
And I will use the function names as keys and then point at
those functions like this.
So now we have these two functions,
which are being exported.
Now let's start with flash data to session because after
all,
we first need to have some data in the session before we can
retrieve it here. I expect to get a couple of parameters.
I need the request object because I need that to access the
session.
I need the data that should be flashed,
and I want to get an action,
a function that should be executed after the data was stored
on the session,
because I will explicitly call the safe method on the
session and ensure that we then only perform a certain
actual, like redirecting after the session data was saved
successfully.
Otherwise we have the danger of redirecting or performing
whichever actually want to perform before the data was
actually saved in the session database.
And they offered a new page,
might be loaded without debt data being ready,
which would defeat the purpose of this utility function.
So here in this function, I will then access dot session.
And now we can add arbitrary data by simply using the dock
notation. And I'll add flash data as a key here.
The key name is up to you though. It's your session object.
You can add any data you want.
And here I'll just add the data under that flash to data key
today's session and thereafter on the session.
Still all calls save,
which has a built in method and I'll pass action to save
because save takes a function as a parameter value and save,
or the session package we'll then execute that action once
saving succeeded.
And that's already all I want to do here now in get session
data. It's not that much more complex here.
I just want to retrieve the data. So I'll add a session,
data, constant and access rec dot session dot flashed data.
And for this to work, of course,
I need to get the rec value, the rec object,
the request object as a parameter value.
Then after I retrieved the data here in line two,
I want to set flashed data to Knoll to clear that data.
And then I'll just return session data.
I don't call a rec session,
save explicitly myself here because it will be saved
automatically. Whenever a request response cycle is done,
we just need to call it ourselves.
If we want to ensure that saving finished before we perform
a certain action here for getting the data and clearing the
data thereafter, that's not that important.
And therefore I don't need to call safe explicitly here.
Now with these utility methods added,
we can use them in the auth controller.
So if we go back to the auth controller here,
I want to import those utility functions and I'll import it
as session flash by requiring.dot util session flash.
So that we now have access to these two functions that we do
export and in the signup function,
which is that function that is triggered upon a post request
there. I want to now flash data,
if validation failed and we redirect to sign up,
or if you already have a user with that email address,
let's start with the validation case here,
I'll then access session flash and call flash data to
session.
Now we need to forward the request object here,
as I mentioned, and then the data which you want to flash.
Now,
it's totally up to you how this data should look like and
how it's structured,
but here all pass an object as data to my session.
And then that object,
I want to provide the error message and then also the user
input so that we saved that for the future.
Last but not least, I'll add an anonymous function,
which is that action that should be executed after saving
succeeded. And in this anonymous function,
I want to redirect. So this is this action,
which we pass to flash data to session.
Now here for D data, which be passed to the session,
I'll start with an error message and it's totally up to you,
which key you use here. It's your data, your object.
I'll go with error message and set the error message too.
Please check your input. Whoops, please check your input.
Password must be at least six characters.
Long postal code must be five characters long.
Now it's totally up to you. What your error message is.
This is a error message that describes which kind of input
I'm expecting and tells the user that something's wrong with
that input.
Now, speaking off that input, we want to preserve that.
And therefore, besides the error message,
I want to pass all the entered data back into the error
message. And for that,
we can of course copy all the data we're extracting up
there.
And I will actually add a new constant here,
entered data where I paste in that copied
extraction and where I will save all that data under certain
keys so that I have one object does entered data object with
all that entered data.
And they can then use that later for flashing it onto my
session.
So that's the enter data constant here and now you're in
flash data. Two session after the error message here,
I will actually use the spread operator,
the free dots you learned about to spread the enter data
into this object.
And you learned that the spread operator,
when used on an object, like enter to data,
we'll take all the key value pairs we have in there.
So email and the value that's stored in it and password and
the value that's stored in it.
And all those key value pairs will be added as key value
pairs in this object, into which you're spreading with that.
We are providing that enter data in that object,
which has flashed onto the session.
Now that was the first step.
I also want to flash data onto the session here in a case
stat, we have an email address that's in use already.
So for this,
I'll also access session flash here and flash some data to,
to session. And that's my request object again,
a data object,
which will populate in a second and then an anonymous
function that should be executed after we saved data to,
to session.
And that's the same function as before where I redirect to
sign up.
And then here, the data that should be flashed.
I still want to have an error message here,
but the error message is user exists already try logging in,
in stat, for example.
And then again, with the spread operator,
all just spread the error,
add the entered data into this object.
So same logic as before,
just with a different error message.
Now that's the signup case.
Since we're already working with that utility method,
we can continue with the log-in case before we then go to
the get log in and get sign up actions.
And we retrieve that entered the data.
So here for log-in.
I also have a couple of checks and specifically here,
I'm checking if the user exists and if it doesn't exist,
we redirect. And we also check the password.
And in these two cases I redirect to log in.
And of course we want to flash the entered data and an
error message to, to session.
So that on that log in page two, which we redirect back,
we can show that.
So again, with Sashen flash flash data to session,
we can pass the request object or a data object.
And then there's a anonymous function where I do want to
redirect in the end and forward is data object here.
I still want to have an error message,
which in this case is invalid credentials.
Please double check your email and password.
And then I want to provide the entered the data.
And the my case needs to email,
which I can get from this user object.
I'm creating here because there I am storing the email and
the entered password. So I can access user.email.
And the password is user dot password.
That's the enter data because that's what we're storing in
this user object up there. Hence we can access it down here.
No, actually it will be the exact same data,
which I want to flash onto my session if the password is
incorrect.
So therefore I will actually cut this object here and create
it as a standalone new constant, which will name, session,
error data.
And that's my object. And then it says session error data,
which I want to flash onto the session here.
And I can now copy that line and do exactly the same here.
If the password was incorrect,
because I want to show you the same error message and I have
to same enter data and the same action.
And now with that, we're flashing data in this case as well.
Now, flashing data is only part of the solution.
We also need to extract the data on the get actions here on
the get routes,
like get logged in and of course get sign up and that's
there for the next step I want to do.