Hacker News Re-Imagined

Show HN: React Routing in 120 lines (including comments)

  • 74 points
  • 8 days ago

  • @ReactNative22
  • Created a post

Show HN: React Routing in 120 lines (including comments)

@aliswe 8 days

Replying to @ReactNative22 🎙

Is the Preact router minimalistic, so to speak, akin to this?


@janci 8 days

If I read this correctly, all the route components are evaluated (i.e. rendered to virtual DOM) and only then one of them is selected and shown (i.e. rendered to HTML DOM). This seems utterly inefficient, even for educational example.


@lexicality 8 days

Whenever I see someone describe how small something they've written as a replacement for a big library is, I wonder what they've discarded in order to get it so small.

Normally it's backwards compatibility, but in this case it appears to be "everything".


@lloydatkinson 8 days

It’s strange that of the numerous frameworks React seems to have the most churn, it’s had multiple ways of “doing state”, there seems to be a new router every year or at the very least a new major (breaking) version of react router.

Why is routing, of all things, in such need of constant development? I say this as someone that’s made SPAs with Vue a lot and occasionally React.


@ldd 8 days

making React small libraries like these is fun.

I made one myself that was absolutely the simplest I could go for[0]

0: https://github.com/ldd/react-simplest-router


@kretaceous 8 days

I'm a big fan of Wouter[0]. Most of my routing needs are taken care of by it.

0: https://github.com/molefrog/wouter


@deckard1 8 days

I've used a lot of routers and my favorite is still page.js[1]. It hasn't been updated in years. But it's small, is Express-compatible (i.e. server/client routes can use the same code), and, more importantly, is hackable. I'll never use a router tied to a certain framework again (react, nextjs, etc.) because you trade flexibility for perceived convenience (e.g. using folder structure as route structure, or React component tree as route structure). But it's a terrible trade-off that paints you into a corner later, IMO. Routing can get really niche and site-dependent, so having it fully under your control is worth it.

[1] https://github.com/visionmedia/page.js


@fatih-erikli 8 days

I use it like that and I am pretty happy with it.

There's one thing, you should redirect all the pages to one single endpoint in server side order to use "pushState". Otherwise it will return 404 when you hit the refresh button. If you don't own a server, you can support routing with hashtag "#" and listen to "onhashchange" event instead of "popstate".

Also, if you would like to support nested and dynamic routes (it's not possible with that code snippet in the github repository since it just checks like `path===currentPath`), you might look at the following solution:


I use that solution in server-side and client-side so it works like Nextjs.


@ThePaulAlek 8 days

I looked at the code in the repo and I can say that it was VERY satisfying to read


@chrismorgan 8 days

> event.metaKey || event.ctrlKey

This misses event.shiftKey. All keyboard modifiers disqualify client-side routing.

As for <Link> in its entirety, where you have to use a special component which becomes a link and adds a click handler to it, I think this is generally the wrong solution: it’s better to instead put a single click handler on the entire document to intercept clicks on links. That way, you can just use normal links everywhere and it just works, rather than having to remember to use a whole separate component every time which may or may not be able to pass through the required properties or attributes (e.g. this one only supports class and href). Simpler, smaller and cheaper.


@martini333 8 days

Why not describe it as 1KB minified? That's way more impressive.


About Us

site design / logo © 2022 Box Piper