Web-App Routing is FUN - the Web is weird, but fun
Tags: showdev, javascript, webdev, cardboard
Published: 2023-10-18 07:55:53


Have you ever wondered how Routers work in frameworks and such? I did not. Until I had to write one for [Cardboard](https://github.com/nombrekeff/cardboard-js). I discovered that they're actually pretty fun to build, and not at all weird or hacky.

Well, I've lied a bit. They're weird and a bit hacky, but pretty fun to figure out. I also more or less understood how they worked (_after years of using many of them_), but not what goes into them in the backend. 

The basic concept is that whenever we navigate to a new URL path, we need to show some content that's linked to that path. But do not reload the page, just change the content.

For example, if navigating to `/home`, we need to show the content for the `/home` route. If navigating to the `/about` page, we need to show the content of the `/about` route. And of course, when we show content, we must hide the previous content.

That's the basics of what a router does. There's more than that, but I'll get to that.

----

### Detecting path changes?

One thing we need before being able to create the router we must first understand how URL changes work and how we can detect when a path change happens.

What do I mean by path change? Well, changing the pathname part of the URL. For example, from this `https://test.com/` to this `https://test.com/home`.

How do we do this in JS? There are a couple of ways of doing this, for example:

* setting the `location.href` directly:
```js
location.href = `https://test.com/home`;
```
It works, but we need to set the whole URL instead of just changing the path. 

* changing the `location.pathname`:
```js
location.pathname = `/home`;
```
The problem with this? You can't change the path relative to the current one. This means that, if you're at `/home/ideas`, and want to change to `/home/contact`. We must set the whole path: `location.pathname = "/home/contact"`.

Another problem with this approach is that every time we change the location, the page will reload. You can imagine why this is not good for SPAs. For single-page apps, we don't want to reload the whole page each time the path changes.

* Using `history.pushState`
The next option fixes this problem and allows us to change the path relatively. This is a win-win, the page does not reload, and we can modify the path relative to the current path.

Imagine we're at `/home/ideas`, and we run this:

```ts
setPath('./contact');
```
> It will change the path from `/home/ideas` to `/home/contact`. This can be done very easily by using the `history.pushState()`

```ts
history.pushState(null, null, './contact');
```

Okay, that's cool and all, but how do we detect when the path changes? Well, HTML has an event that made me hopeful: [`popstate`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event). But it only fires when you go back in the history (i.e. page back).

> **And, of course, of course, there's no event for the `pushstate`... why would there be!**

I might be wrong though, but I've not been able to find an event for when `pushState` is called. If you know how please let me know!

So, what I've come up with is, to modify the `pushState` function and inject some custom logic into it. I don't really like this approach as we're modifying stuff we should not, but it's the only way I've found. 

This is what I mean: 

```ts
const pushState = history.pushState;

history.pushState = (...args) => {
  pushState.call(history, ...args);

  window.dispatchEvent(new window.Event('pushstate'));
};
```
1. Grab a reference to the real `history.pushState`
2. Reasign `history.pushState` to a new function. 
3. Call the real `pushState` function with its correct context.
4. Emit an event on the window for `pushstate`


Now we can listen to `pushstate` events like the `popstate` one:

```ts
window.addEventListener('pushstate', () => {
  // The path has changed!!!
});
```

----

### Reacting to path changes

Now that we can detect when the path changes we can add the logic that will change the contents of the page based on that path.

I will show a very basic example. But know that in reality there's a lot more stuff behind the scenes to make it work, and to make it more efficient. 

The first thing we need is a way of configuring the routes of our app. 

In this example, we'll have a function (`makeRouter`) to handle that. I will not show the complete function as it's a bit long for the example.

`makeRouter` needs a couple of things, an object with the content for each route we want to have (`opts.routes`), and a selector to know where to put the contents (`opts.parentSelector`). 

`routes` will be an object with the route path as a key and a function as the value. Imagine that these functions return [Cardboard components](https://github.com/nombrekeff/cardboard-js/wiki/Reusable-Components). These components will represent some HTML and logic that will be on the page when the route is viewed.

```ts
const myRouter = makeRouter({
  routes: {
     '/home': () => {...},
     '/about': () => {...},
  },
  parentSelector: 'body',
});
```

**myRouter** is an instance of the router object. It should also be possible to get a router from other parts of the app. Imagine there is some magic function (`getRouter`) that returns the current router.


**The router object** allows us to navigate between routes:
```ts
myRouter.navigate('/home');
myRouter.navigate('/about');
```
> This uses the `history.pushState` in the background to update the URL in the browser, and, as we've overridden the `pushState` method, the `pushstate` event will be fired. 

Behind the scenes, `makeRouter` does a couple of things to make everything work:
1. As seen previously in the article, we override the `history.pushState` function.
2. It listens to `pushstate` and `popstate` events:
```ts
window.addEventListener('popstate', () => updatePage());
window.addEventListener('pushstate', () => updatePage());
```
3. It grabs the current path
4. Load the correct route for that path

Now, what happens if the route is not defined for a path? Currently, everything will break! But we can add some more features to our router to make it more secure and ergonomic.

----

### Improving the router

First let's add a fallback route, for when a route is not found, we can default to that route.

Fairly easy, when creating the router, we must now ask for another option (`opts.fallbackRoute`), which will just be the route path.

```ts
const myRouter = makeRouter({
  parentSelector: 'body',
  routes: {
     '/home': () => {...},
     '/about': () => {...},
  },
  fallbackRoute: '/home',
});
```

Now, if a route is not found, it will show the `/home` route.  We could also allow the makeRouter function to receive an option for a route builder (`opts.noRouteBuilder`). This allows us to pass in a function for when the route is invalid:

```ts
const myRouter = makeRouter({
  parentSelector: 'body',
  routes: {
     '/home': () => {...},
     '/about': () => {...},
  },
  noRouteBuilder: () => {...}
});
```
 

Much better, now whilst we have `fallbackRoute` and that route exits, or we have `noRouteBuilder` we'll not have errors. But what if the fallback route does not exist? or no builder is passed? Well, currently, everything will break.

There are a few ways of handling this, and this should be up to each implementation. In my case, I decided that instead of throwing some error, or requiring the fallback or builder, I would just add an error to the page instead, indicating that the route does not exist!

----

### How to show/hide content?

Well, this might be the most complex part of the process, and it all depends on the context where you're building the router. Is it a router for a framework that already exists? Does it need to work in vanilla JS? Is it the core router for your framework? 

After knowing the context ask yourself: Can I do this already in some way? Can I show/hide content with the framework? Do I need to implement it myself? Is there some tool out there that can help me?

These are some of the questions you will need to ask yourself. And based on the answers you will do this in one way or another. 

In my case, as I was building this for [Cardboard](https://github.com/nombrekeff/cardboard-js), and had already implemented a way of adding and removing items from the page very easily and efficiently, I made use of that. 

I will show a little **pseudo-code** example showcasing the  `updatePage` function mentioned above. This function will run each time the path changes (on `pushstate` or `popstate`).

```ts
updatePage() {
  if(previousRoute) {
     previousRoute.remove();
  }
  
  const route = getRoute();
  route.add();
  previousRoute = route;
}
```

This is extremely simple, but the concept is as follows:
* If there was a route already on the page **remove it**
* Then get the current route.
* Add the route (to the parent of the router, defined with `parentSelector`).
* Set the `previousRoute` to the new route.

----

#### Additional Improvements

This example just scratched the surface, there are a lot more improvements that could be done to make it a fully fletched router. Here are some of them:
* Handling parameters (`/users/:id`)
* Handling query parameters (`/users/:id?s=0`)
* Caching contents
* Aliasing routes: `/` -> `/home`
* Reusing elements from one page for the next (this could be the case for frameworks and more complex systems)
* Much, much more!

----

### Summary

So yeah, I think that sums up what a router is and how to create one. Of course not in detail, it will not work if you just copy and paste. I think tutorials or guides like these should not just give you the answer, they should make you think, problem-solve, and more importantly learn. But give a clear view of how it works and show some of the oddities and quirks. I hope this article has done some of that for you!

**Let me know your thoughts:** Do you like this style of tutorial/guide? Or do you prefer a more step-by-step kind of article?

Cheers! That's me for this one. Have a nice one :)

----

### Call to action!

**Feedback needed:** I'm currently working on Cardboard, pouring all my love, and free time into it (_it's a lot, I'm unemployed_). But I need early feedback to make sure it starts in the best way possible. Can I ask you to kindly head over to the [Cardboard](https://github.com/nombrekeff/cardboard-js) repo, take a look at the project, and give me some feedback? The project is open for anyone to help. You can contact me here on DEV, by mail: `nombrekeff@gmail.com`, drop an issue, or comment on this post!