In this video I want to go over one last topic around re-act router.
Now this video is going to be optional so if you are kind of tired of free Kreder and you want to continue
writing some code puzzle video right now and continue to the next video.
Otherwise stick around and we'll get into it.
Now the reason that this video is optional is that this has some knowledge that it's not really going
to be relevant until you go to deploy your application at some point in the future.
Nonetheless this is a really common question that comes up all the time around re-act router.
So I figured I would throw in a quick discussion right now to see what kind of are prepared with this
knowledge right now.
OK so let's get to it.
The core of this discussion is around this browser router thing right here.
Now in total re-act router actually has three different types of routers available.
There is the browser router right here that we've made use of.
And then there are two other routers as well.
Each of these different routers.
The only difference between them is the part of the Eurail that they're going to look at when deciding
what content to show on the screen.
So let me tell you the difference exactly between all three.
All right.
So we have the browser router which we've already used inside of our application.
We also have something called a hash router and a memory router.
Again the big difference between these is the part of the euro that each router is going to use to track
what content the user is trying to view with the browser router.
It's essentially that we discuss so far with the browser router re-act router is going to look for the
top level domain or the TLT that is the dot com or the dot net or the dot edu whatever it is and it's
going to look for everything after that top level domain.
Alternatively if you have a port definition it's going to look for everything after the port definition.
So with the browser router if we have a Eurail like localhost Colan 3000 slash page to react rodder
cares about just flash page to now things start to get a little bit more interesting with the hash router
with a hash router re-act routers going to automatically put a little hash character or a pound sign
into your your L and then it's going to automatically trying to reflect the current path.
After that hash character.
Now that might sound like a really weird distinction to make but we'll talk about why that's relevant
in just a moment.
And then finally with the memory router the Ural is not used at all to track navigation.
Now as I go through these descriptions of each of these they seem a little bit weird.
So I think that the best thing to do to understand the difference between each one is actually use them
inside of our application and that will give you a better idea of the differences.
After we tried putting in each of these routers to our code and tested out really quickly I'm going
to tell you exactly why we use each of these different routers and that's the really important part
for you to understand because that's the part that is actually relevant to deployment.
And I just see you know one other quick thing here.
This is going to be a long video because I'm going to try to fit everything into this one single video
so that if you skipped over this you don't have to like go to the next section where I'm still talking
about the same thing that I just told you to skip.
So anyways let's get to it.
We're going to try out each three of each of these three OK.
Cygne first try out the hash rodder because we've already tried out the browser router.
So at the very top I'm going to change my import statement to hash router or then go down to my app
component and replace browser router with router and hash router like so and then I'll save this all
foot back over to my application and I'm going to enter in localhost Colin 3000 and then I'm gonna hit
enter.
To cause a full reload of the page.
Now when I do that you'll notice that we now get a pound symbol injected into our l automatically.
In addition if I now navigate over to page 2 I'll see that my Eurail has now been updated to be pounde
splash page 2.
So that's like pretty much it.
Believe it or not that is the difference between the browser router and a hash router.
All we're doing now is reflecting the part of the Israel that reactor cares about after that hash character
and any time that you navigate around the page using a link tag react ratters going to change only the
portion after the pound now again it might seem like completely irrelevant or like you know who cares
about this at all.
But there is a extremely good reason for this difference here.
We'll talk about it in just a moment.
Before we do let's try out that memory router very quickly as well.
So I can flip back over to my Abdias file and I'm going to change it to memory router.
And then I'll go back down to the component and change to memory router and memory router like so then
I'll save this and I'll flip back over.
Now in this case I again really encourage you to manually navigate back to localhost 3000.
OK so now once I'm back here I should be able to click on the link and I'm going to see that you are
ill no longer updates at all as I navigate around my application.
OK.
That's essentially a difference between all three.
Now really quickly I want to flip back to making use of browser router just in case you fall out of
this video or stop it at any point in time so that you don't steal the memory router inside of your.
So I'm going to change back to browser router at the top.
And browser router inside the component on both those tags.
Now if I flip back on my application I shall be able to click on the link and I'll see the entire Eurail
change as we did before.
All right so now here's the important part why do we care what is the real difference right.
Why do we care about enemies at all.
Well like I said a lot of this comes down to deployment.
This is a really important topic when you think about deploying your application in particular if you're
trying to use the browser router the browser router which is what just about every tutorial around re-act
router Dohm is ever going to tell you to use is by far the most complicated to deploy inside of any
realistic setting.
Now in many cases doing deployment with browser router is going to be very easy because a lot of deployment
services automatically understand that you're going to use something like browser router to deploy your
application.
And so a lot of deployment services are going to make deployment with Brough's router pretty easy and
straightforward but there are many cases where deployment is going to be extremely challenging.
So let me tell you exactly why that is.
We're going to take a look at a couple of different diagrams.
Onka So first diagram right here.
This is a diagram of what happens when we make a request to local oh 3000 slash page one if local or
3000 was a very traditional server like a very traditional Java or Ruby or Python server that always
returned some H.T. mail as opposed to a reactor application.
So I just want you to picture first second that at local to those three thousand we no longer had our
re-act application.
Instead we had some very traditional server that generates and returns some HMO OK.
So we might type in an address like local 3000 slash page one our browser would then make a request
to our back end server the backend server would then have some logic inside of it to look at the route
that you were making a request for.
So the server would then ask a question.
OK let's see do I have a route for Slash page one.
And then inside of your server code there might be some route handler that says like OK anytime someone
makes a request to slash page 1 generate some e-mail and send it back in the response.
So the server would say OK let's see.
Yup I've got some logic here it says.
Anytime someone makes requests to slash page one I'm supposed to produce a smell and send it back to
the server does so it generates some HD mail and then responds with that each HTML document.
And so a single document gets sent back to the browser and everyone's happy content shows up on the
screen.
Now let's go over the same process but I want to imagine what would happen if our back and server.
This very traditional server did not have a route defined for splash page 1.
So here's what would happen if that was the case.
Or actually I'm sorry in this case I use Page two just make it a little bit different.
So let's imagine now that our server made a request to close 3000 slash page.
So browser makes the request and then the traditional server says Do I have a route for splash page
too.
But in this case no I don't have any route defined for splash page 2.
And so what does the server do.
It responds with a 404 error.
Remember a for a for error is a not found error.
It means that our server had no defined route for Page 2.
And so the server said Sorry I don't know what to do with your request so I'm gonna return an air and
tell you that you made a bad request and I don't know how to handle this.
So again this is what happens with a traditional server.
The point that I'm trying to make here is that with a traditional server if you make a request to some
route that is not defined the server is going to respond with a 404 not found.
And it's going to say I've got no idea what you're asking for.
Right.
That is how a traditional server works.
So now let's think about this entire flow.
But with our re-act development server instead.
So as a reminder right now our application is being hosted by a re-act development server.
This is a server that is running from our terminal.
We launch it every time we start up a new project with NPM start.
This is a server that is running on your computer and each time that you make a request to localhost
3000 you are accessing the re-act development server.
All right.
So let's walk through this flow and see what happens with the reactive elements server.
In particular Now one thing that I want to mention very quickly here before we actually go through this
flow I want to point out the fact that right now our application only has a definition of what to do
for the SLAs for the right of slash page to inside of our app.
Yes file like this app component right here.
At this point we have written absolutely zero code that has been executed by any server whatsoever.
In other words run trying to tell you is that are Riak development server has no idea what the splash
page to route means.
It doesn't know what to do with it.
And so if this was a traditional server and we made requests to page two and the traditional server
didn't have that route defined it would definitely respond with a 404 but the re-act development server
is a little bit different.
So here's what happens.
So we make a request to localhost 3000 slash page 2.
So that makes the request over to that server running on your machine.
Then internally they create re-act out development server goes through a little process that says OK
do I have anything special for the route of slash page to burst it checks to see if there are any development
servers with that name like any development resources with the name of page 2.
Now what I mean by that right there is if you actually go back over to your application and open up
your network request log and then refreshed the page you'll see a list of all these development resources
right here.
For example you see a bundled not just file.
So if we make a request to close three 3000 slash static slash slash bundled Yes we get back a javascript
file with all of our javascript code inside of it.
And so there are some routes defined on this server that are going to respond with some development
resources like a CSSA file or a javascript file or whatever else it might be.
But if we do not have any development resource with that given pathname then react to create re-act
out dev server is going to move on to the next step.
So the next step is it's going to check the public directory and see if there are any files with that
given name like the name page to so if you recall inside of our project directory we have that public
folder with a bunch of different files inside there so we can access all these files right here very
easily by making a request to localhost 3000 slash.
And then the file name.
So for example I could go to local history thousand slash Fab.com and ICAO NLC the Advocaat appear likewise.
I can also try to access the other file inside they're called the manifest chase on file and I see that
case on file appear as well.
So there are some very special names that we can access on our development server or some very special
routes.
But in this case we have nothing defined for the route of page 2.
So this is the important step right here.
This is the absolute critical step for you to understand unlike a traditional server unlike the Trishul
server back over here.
If you ask your development server for some resource that some route that is not defined rather then
returning a 404 error the re-act out dev server is going to respond with your index.
Each e-mail file and that is the total key to how all of this browser router stuff works.
The absolute key to how it works if you ask for any route whatsoever the re-active server is going to
always respond with the index.
HTL file as opposed to returning a 4 0 for error.
Now why is that so important.
Well it's really important because all of our definitions are stuffed into the javascript or the client
side of our application.
Again the server does not know what to do with the path of splash page 2.
So when a user goes over to our application and they click on this link right here to navigate over
to page 2 and we refresh the page we are making a request to our server for the route slash page to
and our re-active server.
If you click on that request and then click on response right here it decides to just automatically
return the team mail file.
Or the index.
Ational file.
And so what happens after that is the browser loads up all that H.T. mail it sees that there is a link
inside of your free bundled jazz file that is the file that contains all of our applications code.
So our application then loads up re-act router loads up the history object that is created by the road
by the browser router inspects the current Ural right here.
It seems that we are out the route of splash page to the history object tells the browser router that
we are at splash page 2 and the browser router tells both the routes right here hey we were at splash
page to surrender yourself appropriately.
So that is what is going on behind the scenes with the browser router.
Now the reason I say that this is the most complicated to set up is that this mechanism of always responding
with the HMO file if the route is undefined is not typical in any traditional server that you're ever
going to work on if you're not making use of some like applications specifically set up for a single
page application.
The default behavior for every server in the world is that if you ask for some route that does not exist
you respond with a 404.
If that was the case with our re-act development server we would not be able to use the browser router
because as soon as you and I typed in a route appear of localhost slash page two that is not a route
that is handled by the development server.
So we would get a 404 error that says sorry that route is not defined.
So that's why it is so challenging to set up or deploy a application that makes use of the browser router
you have to make sure that your server is configured in this identical fashion.
You have to make sure that rather than responding with a 404 if you get some route that you don't know
about your server is going to instead respond with the index on each e-mail file.
That is the part that gets people in trouble when they tried to deploy an application using a browser
router.
All right.
So hopefully that makes a bit more sense at the very minimum at this point you don't really need to
understand like the big details here.
I just want you to understand that when you try to deploy your own application you might end up seeing
an error saying like hey I don't know what route slash page 2 is and that's going to be thrown by your
server.
And the reason you're going to see that ere is because you have not configured it appropriately to work
with the browser router.
All right.
So that's Bressler router.
Now very quickly I want to tell you about the hash router and why we would ever use that.
The reason that we use hash router is very similar to this entire system that we just described.
You know this entire concept of making sure we return an index that each HTML file with the hash Roder
you're supposed to be setting up your back and server to not take a look at anything after the hash.
As a matter of fact I think if we try right now to navigate to like say local host Pound's splash page
to yeah when I navigate over there take a look at the request that is made right here like you can inspect
the local host request and click on headers and if you look at this request right here you're going
to see that there's basically nothing inside here that makes any mention to the splash page 2.
So the reason that we use a hash router is that we can make requests to always localhost three thousand
and we can configure the route local those 3000 slash to always return our index.
Single file and our server should not look at anything after the hash.
The hashes only for use by the client or by the browser.
And so you can say that if anyone ever makes requests to localhost 3000 you're always going to respond
with the index.
HGL file and then when your application loads up your application will then look at whatever is after
the hash and then use that to determine what content to show on the screen.
So essentially a hash router is a lot more flexible because it does not require special configuration
by your back and server.
You can just have a single HTL file at a single route.
You can always make requests to exactly that route.
And then when the application actually lifts up re-act router is going to look at only whatever is after
the hash to decide what to show on the screen.
Now a very good example of when to use a hash router is if you are doing a deployment to get help pages
get how pages does not allow you to do any type of special logic that says hey just go ahead and always
return the index on each e-mail file instead.
Good how pages is always going to expect that you make a request to some defined resource.
And so if you were defining or something if you're deploying every application to get how pages you
can say oh yeah I just come to like my get help pages link and then you can put whatever special path
you have inside of the hash over here and react router.
It's not just me the server is not going to care about whatever is after the hash.
Now I know that example right there I don't have any good diagrams to show you to explain why that is
the case but hopefully later on when we talk about deployment we will get an opportunity to deploy to
get her pages and I'll be able to show you that hash rudder in action and show you exactly why we care
about it and how it solves that particular issue.
OK.
I think this video has gone on long enough.
I hope that I've given you at least something to think about.
When you start going through deployment again all you really need to understand is that when you try
to deploy a browser router if you start to get error messages saying this route is not defined chances
are your server is not set up correctly.
So let's take a pause right here and we'll continue and get back on track in the next video.