- How client-side routing works
- What the trade-offs are for client-side routing
- What
pushStateis
So, we have learned about building components, changing state, passing props,
etc... You may be wondering how you can make an app with multiple URLs that
contain different components. Not every app is a todo list, tic-tac-toe or a
spreadsheet. So how do we build an app that allows us to have unique pages for
the user to interact with? This is where Client-Side routing comes in.
Client-Side routing is a different beast than what we are used to with traditional server side routing that comes with Rails, Sinatra, or Node/Express, because we aren't making constant HTTP GET requests.
Lets say that our Client-Side app is going to have these routes
https://www.movie-maker-2016/movies/new
https://www.movie-maker-2016/movies
https://www.movie-maker-2016/about
https://www.movie-maker-2016/login
Note: these links are examples and do not lead to any website
Our servers only job is to render the HTML. Which will look similar to this.
<!DOCTYPE html>
<html>
<head>
<title>Movie Maker 2016</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<div id="container"></div>
<script src="./bundle.js" charset="utf-8"></script>
</body>
</html>With Client-Side routing, it is now the responsibility of the Client-Side-Code to handle the routing, fetching and displaying of the data in the browser instead of the server.
Imagine you've built a personal blog with a navigation that links your home page, about page and contact page. With Client-Side routing, you might get all the needed data to render all three pages on the first page load. Then, when a user clicks around your site, the Client-Side router swaps the 'home page' component with the 'about page' component and renders faster than it would if you were requesting a separate page from a server.
Client-Side routing brings with it some great benefits. The major one is Speed. Since we are only making one request to the server we don't have to wait for a round trip server call for each page change. We have everything stored on the Client-Side already, so we just notify our Client-Side code to display the info as we need it.
In React we will likely be building a SPA, or Single Page Application. This means we wont require multiple pages being loaded, just the original GET request with our initial HTML, CSS and JS files from the Server. This requires us to figure out how to make the experience of Client-Side routing work to our advantage.
There are a couple of things that we need to take into consideration:
-
We want to make sure that we have a URL that displays what the user is doing at that moment. So if they are viewing a bio page it might look like this
https://worlds-best-app/bioinstead of thishttps://worlds-best-app. -
We want a user to be able to use the browser's back and forward buttons with ease.
-
We want a user to be able to input a URL into the address bar and navigate to the view they need to see.
This was easy with server side rendering: most MVC frameworks come with this for free, because we just defined the routes, added the actions needed to the controller and then made a call to the model to get the info we desired.
So this all sounds great, but what are the limitations?
-
Loading of CSS & Javascript
Since we are now loading all of our CSS and Javascript on the initial GET request it can take a while to load our first page. This can be important as the first page load can take a long time if you have a huge application.
-
Analytics
Analytic tools normally track page views, but a SPA doesn't have pages in the traditional sense, so this makes it harder for Analytical tools to track page views. We will need add extra scripts to handle this limitation.
-
They are much harder to design.
We have to plan out all the possibilities that might happen on the Client-Side, this might feel like we are repeating designs that we have already completed with our server routes and models.
When we make server calls we are making a GET request to a URL and that new URL is in our address bar. If we have visited a few different URL's though that information is saved in browser history.
Go to the JavaScript console in Chrome and type
window.historyThis should return the following code.
History { length: 32, state: null, scrollRestoration: "auto" };The length is how many locations you have visited in this window session.
Now if you type the following code it will take you to the last location in your browser history.
window.history.back();Go ahead and try it out.
............. ............ ..........
Oh good, you're back!! :)
So that is the JavaScript to emulate the experience of using the back button in the browser toolbar. You can also move forward using window.history.forward().
With the JavaScript's History API we also have the ability to pushState() to the history entries. This method takes in three parameters: pushState(state, title, url)
-
state object:
This is a plain JavaScript object that is associated with the new history entry we are going to create with the pushState() function.
-
title:
This is currently ignored by most browsers and it is safe to just pass an empty string or a title here.
-
url:
This is the URL for the new history entry. The browser will not attempt to load this URL after it calls pushState().
Why don't we go ahead and create a new url in our browser
const newState = {
goal: "Learn about pushState()"
};
window.history.pushState(newState, "new state", "new-state");You should notice that your browser has now changed to show new-state at the
end of your URL address.
Go ahead and type
window.history.stateIt should return
Object { goal: "Learn about pushState()" }If you now use the window.history.back() function you will not go back to the previous page, but your URL address will return to the original URL address. If you use window.history.forward() you will move back to our new URL that ends in new-state
We have now successfully implemented a basic version of Client-Side routing.
As we start learning about React Router we will start implementing pushState() within the context of a React app.
The web was designed, from its inception, to be a platform for everyone, including those who need help interacting with it through assistive devices. Those requiring captions, inverted contrast, etc. have all been able to participate in our web because the it was designed with the differently-abled in mind from the beginning.
Creating accessibile sites in the SPA style of application represents an additional challenge. Many tutorials breeze past this consideration.
Designing SPA's that work with accessibility in mind proves you that you're not only a superior developer, but a great person. Here's a blog post on accessibility in React.
View React Introduction To React Router on Learn.co and start learning to code for free.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent