[pscanf]

I've done something similar in a React project I'm working on to avoid dealing with the insanity that is react-router.

Call me naïve, but routing in a single page application is just not that hard of a problem. At the core it's about having a piece of state¹ (your active route) which determines which part of the app you want to render–something you can do with a switch statement². On top of that, you want to synchronize that state to the page URL³.

Doing it yourself requires more boilerplate code, no question about it. But it's not that much code tbh (not very complex either), and you get back control over that important piece of state, which otherwise remains opaque and difficult to work with–i.e., its "shape" is pre-determined by the routing library you use. For example, react-router doesn't support parallel routes.

¹ https://github.com/superegodev/superego/blob/main/packages/a...

² https://github.com/superegodev/superego/blob/main/packages/a...

³ https://github.com/superegodev/superego/blob/main/packages/a...

[embedding-shape]

I also basically re-invent a tiny 50 line router for every web project. Hardly ever go beyond "Map URL -> Page" and "Map URL + Parameters -> Page with properties", and when you do, knowing 100% how it works helps a lot.

I also agree it isn't a hard problem, but personally I'd say you got the flow the wrong way around. You don't want to "synchronize state to the page URL" but rather treat the page URL as something you create state from, so it works both when you navigate there by pressing anchor tags, or the user manually enters the URL, and it gets a bit easier to manage.

Basically, URL is the top-level state, and from there you derive what page, then render that page, rather than the other way around.

[pscanf]

Yeah, implementing it with data flowing one-way only from the URL to the state is cleaner.

Conceptually, however, I prefer to think of my state being at the center of things. I mean, that's where I define (via types) what the state is. The URL is just one serialization of that state that is convenient to use in a web browser (making it work with links, back/forth buttons, etc). Maybe in another environment another serialization would be needed. Or maybe no serialization could be needed at all (making it a memory router).

[sampullman]

I don't think it's naive, I often do the same in Vue. A pretty useful subset of vue-router can be implemented in less than a tenth of the bundle size.

[johnfn]

If you are just working on a small website and you don't care about SEO or supporting more than, I dunno, a thousand users, then sure. But if you ever expect to do more than that, I might call you naive, yeah. One big thing: what if you want to support SSR, which I think is a pretty basic requirement these days? I'd submit that supporting SSR will take you a bit more than 50 lines.

[pscanf]

That's why I emphasized _routing in a single page application_. If one needs SEO, a client-rendered single page application is the wrong choice, regardless of the router.

> One big thing: what if you want to support SSR, which I think is a pretty basic requirement these days?

I agree it's a basic requirement for a certain class of apps and websites, but there are tons of apps for which SSR is not relevant and even detrimental (in the sense that it adds complexity that is not offset by the benefits it brings).

[simon04]

A very tiny router is provided by nanostores: https://github.com/nanostores/router