Now, what are some of the last two files you see?
Solution three and solution four.
Well, these are optional.
And there are ways that we can improve upon our app to address some of the edge cases.
So what's one edge case?
Well, one edge case is what if the user types in a country that doesn't exist and they click add?
Well right now our app either hangs or it crashes, which is not what we want.
Instead, we want the error to be handled.
And for us to get a update in the placeholder of this input, instead of saying enter country name,
we want it to say country name does not exist, try again.
And equally, if we tried to add a country if we've already added.
So for example, you can see Colombia has already been added.
Let's try adding it again.
Well what should happen in this case?
Well, if we click add we want to get an error that says country has already been added.
Try again.
This is going to involve us to modify our code a little bit.
And as I said before, this is completely optional.
If you want to end this application right here, then that's the main point of this lesson completed.
But here's some optional improvements.
What we want to do is we want to add a try catch block around some of these queries.
This query says look for the country code from the countries table that matches the user input.
Well, if that doesn't work.
So if we caught the error in this case, then that should take the user back to the home page.
But instead of using redirect back to the original home page, we can simply do a dot render and pass
over an error as well.
Because if you take a look inside the index.js, you can see that in the input.
I've got the placeholder set with some JS to display.
Either enter the country name or if there is an error that's being passed over using JS, then display
the error.
So that means we can send that over from our back end.
Now the other try catch could wrap around this block.
In this case, if we try to insert into our visited countries and it error out, it's probably because
the value that we inserted already exists in there.
And remember, when we set up this table, we said that the country code has to be a unique and a non
null value.
If this one has an error that's caught, then we can send a different message and rerender the index.js
page.
Now if you don't want to try this and you just want to take a look at the way that I've done it, then
you can simply head over to solution three.js.
And I've got the try catch blocks wrapped around giving us the error catching that you've seen here.
Error catching is kind of like a long and tedious process, but it does make your application more rounded
and a little bit better in terms of user experience.
So if you want to give it a go.
Pause the video.
Now, if you don't, then continue with me and I'll walk through the solution together.
All right.
So let's take a look at the solution in solution three.js.
Remember that I had already split out the function here that checks for all of the countries in our
visited countries.
And this is useful because we're going to use it very soon.
So the first try catch block wraps around this query.
Look for a country name that matches what the user put into the input.
If this fails, it's going to go into the catch block and we want to log that error.
But also we're going to grab hold of all the countries that are already visited.
We're going to rerender the index.js.
But this time, in addition to passing over the countries and countries dot length, we're also going
to pass over an error message.
Country has already been added.
Try again.
Now.
If this try block fails, then it's going to be caught all the way down here in this catch block.
You can see how we handle that error.
So firstly we go ahead and log the error so that we can see as developers.
And then we go ahead and use that check visited function to grab hold of all the countries that have
already been visited.
Then we rerender the index.js passing over not only the countries data, but also an error string.
And we're telling user that the country name does not exist.
Try again.
Maybe they made an error.
Maybe they made a typo.
But either way, we get that error message into the placeholder of the input.
The other try catch block that I've added is around this other query, where we try to insert into our
visited countries table.
Now, you might remember that when we set up the table, country code has to be unique.
So if this already exists, this code that we're trying to insert, then we're going to catch the error
in here.
So we log the error and we again rerender index.js passing over a different error message that alerts
the user to the issue.
So that's our error catching and improvement.
Now one final improvement that I made is when you look into this countries table, you can see that
some of the countries have really really long name.
Right.
So for example Tanzania is not stored in here as just Tanzania.
It's actually stored as the United Republic of Tanzania.
And that is the only way we can get hold of that country code.
What are the chances that your user is going to know that in order to get Tanzania, it is Tanzania,
comma.
ET cetera, et cetera.
Well they're not.
So they're just going to add it as Tanzania.
But in this case we get the error that we added earlier.
Country name does not exist.
Well it obviously does exist.
It's a beautiful country and you can hike a really beautiful mountain.
But if we want to address this, we're going to have to think back to something that we learned in the
last lesson, which is the where like pattern.
In this case, we can use where like in order to match a particular word or string in a column in a
fuzzy way.
If you don't remember this, I recommend heading back and reviewing this part of the lesson.
But if you're still following along with me with these challenges, see if you can figure out how you
can use this type of SQL query to be able to match just one part of the string.
We want to be able to allow the user to insert something like Tanzania, and even if there's something
in front of it, even if there's something after it, as long as that word exists in our country name,
then we'll check that as a match and give them the country code to work with.
Pause the video.
Afterwards, I'll run through the solution together.
Now the only modification that we really had to make in order to allow this to work is the SQL query.
You might remember from previously, we can use the where like commands in order to loosely match a
particular column to a particular value.
The pattern here that we've got is we've got a wild card.
A wild card.
And in between we've got some concatenation, some concatenation.
And then we've got the input.
So what does all of this mean.
Let's say that the input is Tanzania.
This part of the code is going to merge a percentage sign to the front of it a percentage sign to the
back of it.
That's what these double pipe signs do.
It's not 11.
It's not two I's.
It's actually a pipe symbol.
And this gets interpreted by SQL as as you can have any text in front of the word Tanzania.
You have any text behind the word of Tanzania, as long as Tanzania exists somewhere in that value,
then will provide a match.
And we're going to give you the country code that matches that record.
Now, the other part of the code you might have noticed is I've got one more modification, which is
I'm changing the input to lowercase by using the to lowercase method from JavaScript.
And this means that when the user types in Tanzania, it's going to be converted into all lowercase.
And then over here I looked up the SQL command to change text to lowercase, which is wrapping it inside
this lower command so that the original, which is Tanzania, Republic of et Cetera all gets lowercase
as well.
And what this helps us with is in case the user typed in a lowercase country, then it's going to match
the country name even if the casing is not correct.
And that means if we now go ahead and run solution Forge's our final version.
And we type in a country like Tanzania in here, even though we know in our table it's trying to match
against Tanzania.
Republic of if I hit add, you can see it gets added without a problem.
These are just some small edge cases that you can think of, and you can discover while you're testing
your app.
And you can address them one by one by making your SQL more precise or handling your SQL errors in a
better way.
Now, you'll probably discover tons of other edge cases that you want to fix as well.
But this is just a process of software development where we identify edge cases, identify bugs, identify
user experience snags, and then try to use our code, in this case improving our SQL code to address
it in a better way.
So I hope you had fun building this world tracker with me.
And if you've been to a ton of places and you want to share a picture of your world tracker that's got,
I don't know, maybe you've been to 200 countries or something crazy, then do that in the Q&A section.
I look forward to seeing places you've been to in the next lesson.
We're going to continue with PostgreSQL, and we're going to dive deep into establishing relationships
with Postgres.
So for all of that and more, I'll see you there.