If you’ve been programming using React or have thought about using React, there is a high possibility React Router has come up in conversation as a way to handle client-side routing in React. This post aims to cover the higher level understanding of server and client side routing, and how React Router might be a great option for you if you’re able to harness its power.
But first…What is the difference between server-side routing and client-side routing?
SERVER SIDE ROUTING
The more common approach to handling routes is server side routing. Server side routing is not part of React Router but it is still the most common form of handling routes. With server side routing, a user clicks a link that requests a new page or new data from the server (another computer). And then new data or document is served to the user.
Let's break this down a little more:
When a user clicks on a link on a webpage, another whole page is loaded and rendered onto the screen. The url path is updated to match where the user is in the current state of the web page. This “whole page” that is loaded and rendered is done through the server. Server side routing is what causes the whole page to refresh because we are making another request to our server, which is providing us with a brand new page to display. In steps:
User clicks on a link on the webpage
User clicks on a link on the webpageThe link sends a request to the server (another computer)
The server responds with the new content
This content refreshes the information on the user’s screen
The url is updated to reflect where the user is at on the webpage
It is the server that is serving up the contents and files for the browser to display for the user.
The main drawback to using server side routing is the varied time it can take content to display on a page. If the page the user is requesting will still have that header and footer information being displayed onto the screen, then why would we need to reload this information? But the server doesn’t know that we don’t have to reload that information because it’s already being displayed. The server will send back the file that needs to be displayed and then call for a full refresh to get this new file displayed. With the full refresh, we now bring internet speeds into the equation. Internet speeds contribute to the time it might take for something to be displayed onto the page.
But how can we prevent this complete page refresh and possibly slow down our render time?
Client side routing is the internal handling of a route inside of your JS file that is rendered to the front-end (or client).
CLIENT SIDE ROUTING
The reason client side routing has become something more developers have been considering when creating their apps is due to the popularity of creating single page applications (SPAs). With a SPA, when a user clicks on an internal link within your application, the goal would be to see a change in the url bar to show that there is an update happening to the page without a full page refresh. With a SPA, we don’t require multiple pages to load, just the original request with our initial HTML, CSS and JS files from the Server. Because of this, client-side routing is used to create that SPA experience while making the routes more uniform and organized for our users to see. The routing is to make our users have a better experience overall because they are able to pinpoint with the route in the url bar where they are at in the application, all without us needing to make multiple server requests.
BUT WHY DO WE CARE?
It gives the user a url that makes more intuitive sense to be able to see where they are currently at in your application
We want to give the user the ability to use the “back” and “forward” buttons in their browser
It gives the user the ability to type in a specific URL and be able to load that specific view in the application
The application will have less lag time between different links because the information that is needed to render the next view was already loaded after the initial load of the page
REACT ROUTER’S APPROACH TO CLIENT-SIDE ROUTING
React Router takes a more dynamic approach to client-side routing. But what is the difference between the two?
React Router is a collection of navigational components that compose declaratively with your application.
Now every time a user clicks on a link, this will call on that routes.js file you created and look for the endpoint that matches the link that was clicked on. This creates an extra step after the link is clicked because now the server is called to respond to this request. The problem with this is that these requests take time to be resolved. This new request time can vary depending on the strength of the connection making this call to the server file.
However, if you have used React before, you would quickly come to realize this wouldn’t be the “React way” to do this. To prove this further, in older applications with React, you might have gone as far as having to create your own API with the same functionality as your component lifecycle methods.
With dynamic routing, routes are updated as your app renders. In other words, the route that is seen in the URL bar is updating for the client to see, however, there is no communication with any server for that to happen. React Router to its core is a component. This means adding router functionality to your React app is done the same way you would add any other functionality to your React app.
Let’s dive into this in the example below:
In the above example, we’re importing BrowserRouter into our application and using the functionality to match the path, but the true power of dynamic routing with ReactRouter is like this:
So what did we just see?
When we match the url with a UserId, the displayed route for the user is going to be rendered using the match property to now match the specific url with the id that is passed to the match.params.userId into the
React Router allows us to keep the uniform links while keeping true to the dynamic rendering and routing of React, but like everything else in technology, there are certainly cons to using dynamic routing. A key con is that the initial request to the homepage can take longer. Since the whole page needs to be loaded on the initial load, this can cause that initial request to the homepage take longer than it would if all of the app’s contents wouldn’t have to loaded immediately.
In summary, I think it’s best to know both client and server side routing and then you can decide which you would prefer to use for your application. Server side routing is still the standard, but client side is making a splash for a reason.
If you're interested in learning more about React Router, below is a link to the React Router Documentation that was referenced for this blog: