I love re-act router. 2
But there definitely are a little couple aspects to it that are maybe a little bit more challenging 3
to understand than you might expect. 4
One in particular is the difference between browser history and hash history. 5
In this video we're going to talk about the differences between browser history and hash history. 6
And then we're going to do a deep dive in how we make use of browser history in a production type environment 7
. 8
So there are some little subtleties in there with your server set up that we'll make sure are really 9
clear when you're using browser history. 10
So let's get started. 11
I've got an application put together already. 12
I've got two existing routes. 13
One is the route route which is just forward slash and then I've got the users route which shows me 14
this users list component. 15
Now this app doesn't really do anything special right now so let's check in on the browser. 16
I see the app component right now I'm on localhost ADHD so I can only matching the app component and 17
if I go to slash users I now see my users list. 18
So here's the user list right here. 19
So right now I'm making use of browser history. 20
So first point discussion what is the difference between browser history and hash history both these 21
history objects are doing one thing for reactor out or exactly one thing. 22
It is telling re-act router which part of the Eurail to consider when deciding what components to show 23
on the screen. 24
OK. 25
So in that case with browser history which we're using right now we're saying hey re-act router. 26
Whenever you decide to render some stuff to the screen I only want you to look to the right of the TMD 27
where the Tildy is like your dot com or your dot you or your dot gov or whatever it might be. 28
So if in that example dot com slash user's browser history is going to tell re-act router only consider 29
slash users when deciding what components to show on the screen. 30
And that's exactly the behavior that we just saw in the browser. 31
Right. 32
We saw localhost slash users and then we got our user list on the screen. 33
So not that not bad hash history is very similar nearly identical with just one tiny difference how 34
history tells you that router find a hash in the URL and then everything to the right of the hash is 35
what you should use to decide what to show on the screen. 36
So I got flash users or Zimmy hash slash users and I would expect to still see the user list so I can 37
very simply change out my browser history object here for a hash history. 38
And now if I let's say that I go back to localhost ADHD you can see that automatically and I know this 39
is really small on the screen but unfortunate I can't really dial up the. 40
OK. 41
That works for you. 42
So you can see that. 43
Now I got a hash automatically inserted into the URL and everything off to the right hand side is what 44
we're going to consider when deciding what to show on the screen. 45
So if I then click on users I get hash. 46
Slash users and boom I got my users list. 47
So the sole difference in browser history and hash history is what part of the world do I look at when 48
considering what to put on the page. 49
OK. 50
So that's that's the easy part of history is right that's the part where of course you can check the 51
documentation and figure this part out. 52
This is the easy part. 53
Why. 54
The real question is why in the world would we use one or the other. 55
Why would we use one of the other. 56
There's really two good answers to this. 57
The first off is the obvious one the obvious answer. 58
Obviously you would want to use browser history if you want to have what is referred to in that industry 59
as pretty you or else. 60
So your L that looks right you know reasonably human legible something you could pretty easily type 61
into the address bar if you had to. 62
Whereas with past history you don't really get that benefit you got that presumably ugly hash in there 63
to figure out what your you are is. 64
Now I've never really sat down with a common user out there and said hey Which of these two do either 65
these two really repulse you. 66
Right. 67
But the inclination in the industry is that if you want pretty you or else you're going to go with your 68
browser history so you don't have to deal with that hash. 69
OK. 70
So that's that's the obvious one right. 71
That's the obvious one we do have to do with the hash but is there any other reason beyond that. 72
And in fact there is there is a very distinct very good reason where you might use hash history over 73
browser history. 74
Let's talk about hashes first. 75
OK. 76
Let's imagine for a second that I'm working on an existing gigantic application. 77
It might be Rail's or Django flask. 78
EXPRESS Any any existing back end server right. 79
Let's say that I've got some existing server put together. 80
And when a user goes to let's say local assiduity we can imagine example dot com or something like that 81
. 82
And then if they go to admin just like so and we say whenever someone goes to slash admen that is going 83
to access some route on our existing server and load up some like Agnon. 84
Each team mail file case we've got for this route right. 85
You're a very specific response coming in from the server. 86
But on top of this route once someone gets here once they load up slash Admin we then want to load up 87
some front and re-act router application that would be the use case of hash history. 88
So what I'm kind of getting out there I know that's not entirely clear is if you are working off an 89
existing server with a ton of existing routes set up and you want to just throw on top of it a reactor 90
outer application that is exactly where you would use Hashi history. 91
And the reason for that might not be 100 percent clear until we talk about why you would not want to 92
use browser history for it. 93
So at this point in time we're going to do a little bit of pivot here and talk about browser history 94
and why it's set up for a production environment is a little bit strange and something that you really 95
need to be aware of especially when you're trying to work with legacy applications. 96
OK. 97
So let's figure this out. 98
I'm going to change my history back to browser history and I'll refresh the page and I'm going to clean 99
up the oil. 100
So. 101
OK. 102
Local as ADHD. 103
Totally fine. 104
Now I'm going to go to a user's OK slash users. 105
Everything looks good. 106
Everything is happy. 107
This is perfect. 108
Right now I want to point out to you that the server that I'm running off of you know that serving this 109
application right here is a web packed web server so dev server. 110
Not something I would want to use in a production environment. 111
So we are going to create a new server right now. 112
It's going to be a tiny little Express application and we're going to pretend that maybe it's going 113
to grow really big over time and the entire point of this. 114
The reason we're creating a separate server is to kind of illustrate some idiosyncrasies of browser 115
history. 116
So let's put this server together. 117
I mean to create a new file called server. 118
Yes. 119
And inside if you we're going to put together just a tiny little Express application. 120
So import express I'll declare a path and my port and then I'll create my express application 121
I'm going to tell express to serve everything out of the current working directory so that's going to 122
give anyone who comes to my server they could get access to like my stylesheet. 123
So style that CSA us stuff like that. 124
And now I'm going to put on Abda listen on port. 125
It will cost lives server started. 126
OK. 127
All right so what we're going to do here is we are going to take advantage of the fact that if you go 128
to a server or some like root path or some folder or some directory if you are not accessing some specific 129
file in that directory you will be served up index page to you now. 130
OK so this is exploiting something basically as old as the Internet. 131
If you are not specifying a file you will get served up index HVM out. 132
So right now because I put in this line right here that basically says Serve the current directory give 133
everyone access to this folder right here. 134
If they come to localhost 1880 when I navigate to that I will be automatically served up index HTML 135
. 136
So let's test this up and browse a really quick stop my web packed web server 137
and I start up my notes server or refreshed the page and. 138
OK. 139
Looks good. 140
I definitely gotten each HTML document right here and it appears that I got my style sheet. 141
I got some stuff from bootstraps VSS but I do have a 4 or 4 on my bundled JS files so bundle that guess 142
is the compiled or kind of bundled I suppose for lack of a better term javascript file that represents 143
my entire app it's got react in it. 144
Scott re-act router redux. 145
All the code that I wrote all that kind of stuff. 146
So when I'm using web pack a bundled up G-S file is not created. 147
It is actually serve from memory. 148
So just as this is a total sidetrack right here by then create a bundle that G-S out of my current application 149
by running well-packed Mashpee. 150
And so it takes just a second. 151
OK so now you can see that I've got bundled JS this directory which means if I refresh the page. 152
OK here's my app again. 153
So what's it to begin with like what happened here. 154
What did I just change. 155
All we did was we went from using well-packed server to start up our application to using a tiny little 156
Express application. 157
And again the whole point this where we're going to come full circle here is explain some of the idiosyncrasies 158
of browser history. 159
I know that we're kind of doing this in a roundabout manner. 160
Anyways back to the topic at hand. 161
Only something really interesting here. 162
So I'm at local hosts ADHD and you can see that clearly the applications rendering I do have an error 163
in my terminal down here but it's just about hey you're doing something production. 164
It's really nothing relevant right now. 165
So might look close. 166
ADHD and I've got a link right here that will take me to my users list so when we go there so I click 167
on it. 168
I now see my user list component on the screen and I've got in the Urals slash users. 169
So I'm clearly at localhost ADHD slash users and I've got my user list on the screen exactly as I expect 170
. 171
OK so I'm going to throw a wrench into this whole thing and you're going to just totally totally destroy 172
this gay area. 173
I just refreshed the page and also I get on the screen cannot get slashed users. 174
Well what the heck. 175
I was just looking at slash users. 176
I was just there and I saw slash users. 177
But when I refreshed the page or when I tried to go there manually I very clearly get a 404. 178
And this is a 4 or 4 generated by express. 179
So this is our servers saying hey what are you talking about. 180
I got no idea what you're talking about slash users. 181
OK. 182
So but if I go back to local as ADHD and I can click on the link again and I go to slash users. 183
So what in the world is going on here what could cause this kind of behavior. 184
Well let's walk through a lifecycle of our of our application right now. 185
So this is our application lifecycle and there's a lot of events in here. 186
So it's two separate slides Let's go through it and I know you can read some not going read these you 187
know steps off to you but I want to give some explanation about them. 188
So first thing we did was we went to a local host ADHD when we did that. 189
We hit the root route of our node server. 190
So we hit basically forward slash because we didn't not specify a file. 191
We were given an index each time out. 192
And again this is a rule that is as old as the Internet. 193
If you hit a route and there is no file provided in the address you will be given index page timeout 194
. 195
So index each email gets sent back to our browser and loads up it grabs our bundled Zsa's file everything 196
kind of starts to boot up it loads up eventually. 197
Are re-act application boots up re-act router starts up and it looks at the you around. 198
And this is the important part here. 199
When re-act router starts up it looks at or L and immediately decides what set of components to show 200
on the screen. 201
So because we were out the route route we saw the app component on the screen right. 202
That's that's exactly what happened. 203
All right so let's let's continue on here for a little bit after that the user me in this case I clicked 204
a link on the page and specifically I clicked a link tag not like an anchor tag but a link tab which 205
is provided by re-act router. 206
So when I did that the address bar updated and then heres the huge key this is the like total big deal 207
the whole big point of browser history right here. 208
When my address bar updated I did not make a new request to the server. 209
Ok so what browser history does when you navigate around on the page using link tags or when you use 210
like browser history dot push or whatever it might be when you navigate around inside of your application 211
. 212
You are not making a new request to your server. 213
You are just artificially manipulating the URL in the address bar. 214
That is all you're doing. 215
You are not making a follow up request. 216
So now that there is a new address bar or a new address in the address bar re-act router decides to 217
show a new set of components and so it's our user list on the screen. 218
Then when we refresh the page that was when we actually tried to access slash users on our server which 219
results in the 404. 220
So the huge distinction here the big kind of surprise with browser history is that when you're navigating 221
around your application it is always soling navigation inside of your application. 222
The address bar updates but there is no actual new request made to the server only when you refresh 223
the page or type in you are l manually and hit enter. 224
Do you try to access slashy users on the server. 225
In our case we didn't have that route defined and we didn't have Flash users defined so it resulted 226
in a 404. 227
Oh OK so that's it. 228
That's why things don't work. 229
That's why it doesn't quite happen as we expect so of course. 230
How do we fix this. 231
How do we get it working the way we expect. 232
So this is the part with browser history where you got to do a little bit of setup when you moved to 233
this production environment. 234
When you're working in your Devyn varmint and you're using web packed dev server well-packed F-Series 235
taking care of all this behavior for you if you tell it to. 236
And a lot of the times the boiler plates that you use will have this setting or everything already set 237
up to make well-packed dev server behave in the way you expect. 238
So in a production environment how do we deal with this. 239
How do we make sure we get the right stuff. 240
So let's say that the user types an address and that could be slash post user's images jibberish or 241
just slash. 242
So here's the key. 243
Here's what our server is going to do no matter what route they try to visit. 244
We will always respond with our index age TMLC file when a user is served the index each file and that 245
ational files load up in the browser their browser will then attempt to grab the bundle JSE file because 246
we have an actual script tag in there to go and retrieve that script file. 247
Once they get the script file re-act router will boot up it will look at the address bar. 248
So you look at the URL and it will show a set of components on the screen. 249
Hopefully the ones that correspond to like Slash posts or slash images. 250
So this is how we set up our server when using browser history. 251
We make sure that no matter what route a user is accessing they get always sent to the index each time 252
a file and then re-act router will boot up and decide what Compounce to actually show on the screen 253
. 254
So let's fix up our node server to make that happen. 255
And in practice it's really darn straightforward. 256
Zangana to add a route using express and give it a wildcard matcher here. 257
So this basically says whenever someone makes a get request to any address whatsoever. 258
Run this function. 259
And inside this function all red dots and file 260
index page HTML. 261
So what this line right here is doing is it says Go and find index H.T. amount inside of the current 262
folder which are cases you know right here and send it back to the user. 263
That's it. 264
So no matter what route the users try and access send them indexes seamount. 265
So I mean to stop this over here and restart my server. 266
And now on localhost I get local as ADHD. 267
OK everything works but it worked before I can click on the users. 268
It still works. 269
And now I can refresh the page. 270
And when I refreshed the page the server sends me index each T.M. then re-act router takes over. 271
Decides what to show on the screen and boom I get my users list anyways. 272
So now I can go to any you or I can possibly imagine I will always be given my index each HTML file 273
. 274
Sometimes it might not work but that's totally fine. 275
So in this case I have an error message in my consulate's says a re-act rudder says that I've got no 276
idea what route you're trying to go to which is totally fine. 277
Totally what I expect. 278
Whereas the real. 279
So it's totally what I expect. 280
Right. 281
Like retractors saying I don't know what route you're trying to go to here but the important distinction 282
is that in this case re-act router did actually get loaded up into the browser. 283
So we are actually loading up the index each T.M. we're getting the right stuff on the screen. 284
OK. 285
OK. 286
So this is how we make browser history work in a node application. 287
But the one little distinction here the one question you might have was well Stephen you're saying that 288
no matter what route I go to I'm always going send a message to e-mail. 289
How do I send like an API request. 290
You know how do I respond with Jaison for some API endpoint. 291
And the answer is that you still can. 292
So I'm going to add API to post on your 293
side if you're all ID one. 294
So just you know whatever. 295
Basically if someone gets does a get request to slash API slash posts send them back in array that has 296
one object with an ID of one. 297
So just kind of a dummy Json end point here. 298
What I want to point out to you in particular though is that I added this route handler above the catch 299
all route down here. 300
So the way that express works is it looks the order in which you define your routes is the order in 301
which Express will try to match them. 302
So because I define this route handler before this matcher or this kind of catch all down here I will 303
make sure that I always send back a few I-Slash pose. 304
If someone tries to access this route so if someone goes here theyre not going to get the index H.T. 305
mail file if they go here theyll get the Jaison instead. 306
And this happens solely because I put the handler above the catchall. 307
So now I should be able to go to API slash posts and I get an array with object id one on the screen 308
. 309
All right so inclosing browser history Housh history some very small differences when you are using 310
browser history you always got to be aware of how your application is going to behave in a production 311
vitamines specifically. 312
You need to make sure that no matter what happens you send back your index to mail file and you are 313
going to rely upon re-act router to decide what to show on the screen. 314
So thats it. 315
If you enjoyed this webcast I do weekly videos on Express redox re-act javascript's. 316
You know just all kinds of things. 317
Check out reli coating dot com sign off the email list will send you one tiny little email once a week 318
with an interesting topic just like this. 319
I hope to see you next week.