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

https://github.com/ashok-khanna/react-snippets/blob/main/Router.js

by ReactNative22 • 4 years ago

74 68 4 years ago

martini333• 4 years ago

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

ratww9• 4 years ago

The author's goal in this seems to be education, not really optimization or replacement of a bigger framework. And I guess this would probably be much less than 1k!

franciscop• 4 years ago

1kb is likely a lot more than what is shown here; I made a "tiny" but very complete React Router package which is very complete and minified+gzip it's just 1.8kb https://crossroad.page/

KhalPanda• 4 years ago

Or "React Routing in 70 lines, with 50 lines of documentation".

lloydatkinson3• 4 years ago

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.

ratww9• 4 years ago

Because making a simple router or simple state management library from scratch is quite simple. So a lot of people do them to learn how the internals work, like this case here. This makes people better programmers. Some of those folks will then decide to continue the development, put some special things here and there and release it to the world to see if anyone is interested in their version of it. Most of those are ignored, which is fine.

However this makes some people vocally angry, because in theory a developer should know every single packages in the world, but never the internals. Only people of a higher class or caste should be allowed to release stuff to the world. The rest are peasants. How dare they. /s

m00dy• 4 years ago

very well summarised :)

chiefalchemist• 4 years ago

Agreed. But at the same time aren't there other things to address, to tackle.

This won't be popular: but tech self-proclaimes itself as innovative and then wastes time mucking around reinventing wheel after wheel after wheel.

Sure, the self-edu is helpful. Of course. But does that always have to a wheel we've seen before going down a road we've been down before?

Note: Not trolling or ranting. Just looking for new thoughts and ideas.

andybak• 4 years ago

I think you're being uncharitable.

The reason people say this is because the scale of the problem is much, much worse in front-end javascript than in most other language communites and it's a real problem for people attempting to get to grips with best practice.

If your explanation was correct then we'd see the same problem everywhere at the same scale but there's something about front-end javascript that seems to exacerbate this issue.

lloydatkinson3• 4 years ago

What a ridiculous hyperbolic comment in response to a question around why one particular library has a ton more development than any others in the same space.

GiorgioG• 4 years ago

React isn't a framework. In order to build an app, you have to cobble together a bunch of other libraries to use with it to build something meaningful.

As someone coming from an Angular shop, I started a new job a few months ago that uses React on the frontend. My main gripe so far is there is no one "way" to do X in a react-based app. For an enterprise with lots of developers, Angular seems like a better fit - unless you want to spend months coming up with standards. Angular has its own issues of course - it's much more rigid and has a steeper learning curve.

Rafert• 4 years ago

Isn't that the gap the likes of Next.js are filling?

lloydatkinson3• 4 years ago

Are people still having this strawman argument over if react is a library or a framework? Would my argument have changed if I'd put "framework/library" in my comment? No.

hobofan• 4 years ago

Why is routing, of all things, in such need of constant development?

Because requirements change. In the last few years there was a lot of churn in React due to the introduction of async rendering and server-side rendering, and React routers were strongly affected by both of those changes.

a_wild_dandan• 4 years ago

React is a view library. It deliberately focused on doing one thing, and doing it well -- declaratively painting the view layer. It's not comparable to more general/monolithic frontend development solutions like Angular/Vue/etc. Those tools have far different scopes. So of course React doesn't prescribe routing, state management, project styling solutions, build bundling, or any other frequently lamented "missing" features. They're only omissions to folks misunderstanding React's use case.

Now there are solutions comparable to Vue/etc which use React -- Next.js, Create React App, etc. Comparisons, tradeoffs, and criticisms are totally fair there. Just don't blame React for churn in third party implementations of features outside of its purview.

As a side note, I love that React is so narrowly scoped. It lets the community build on, experiment with, and coalesce around amazing solutions to other big features outside of React's scope. That Darwinian approach has created broad front end solutions that to me are a joy to use compared to similarly featured frameworks like Angular.

mhoad3• 4 years ago

It doesn’t actually do it well and has been totally out of step with how modern browsers work for years now. It’s old and poorly made technology. The fact that it chose to do one thing and it can’t even get that right says a lot about it.

Sadly, for reasons that remain a mystery to me it’s one of those things like Apple or crypto where some of its loudest fans have decided to make it a part of their identity rather than a tool they enjoy using.

lexicality2• 4 years ago

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".

jrvarela56• 4 years ago

Yeah huh? It's like 'I'm selling the cheapest bag of chips ever' and it's just cuz you're putting less chips inside lol

These short libs are apples to oranges unless we have a test suite or set of acceptance criteria. Something like https://todomvc.com/ and https://eugenkiss.github.io/7guis/tasks helps keep reqs constant.

ReactNative228• 4 years ago

I don't get it...this is a simple library that people can use without bringing in external dependencies. Of course it won't be as functional as React-Router - that goes without saying!!

delaaxe2• 4 years ago

You're trying to argue with a code golfing exercise

kretaceous• 4 years ago

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

aliswe• 4 years ago

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

ratww9• 4 years ago

Preact-router is more feature-complete than this one, but most of the code there is due to the more ergonomic API.

ThePaulAlek• 4 years ago

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

ReactNative228• 4 years ago

Thanks :) :)

janci• 4 years ago

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.

ratww9• 4 years ago

You read that incorrectly. Only the active route component is returned by the Router function, therefore React's render() won't do anything with the others.

chrismorgan9• 4 years ago

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.

wonderbore2• 4 years ago

All keyboard modifiers disqualify client-side routing

Don't forget clicks other than "left". Middle click can open a new tab.

chrismorgan9• 4 years ago

The middle mouse button doesn’t trigger a click event, but rather auxclick (like right click also doesn’t, but rather contextmenu and then auxclick if that’s preventDefaulted).

But there are definitely situations where it’s judicious to check event.button, and I missed altKey, too. Here’s the full function Fastmail uses:

  const isClickModified = function (event) {
      return (
          !!event.button ||
          event.altKey ||
          event.ctrlKey ||
          event.metaKey ||
          event.shiftKey
      );
  };

math-dev2• 4 years ago

Would you have an example of how to do that?

chrismorgan9• 4 years ago

Here’s a starting point:

  addEventListener("click", function (event) {
      const link = event.target.closest("a");
      if (
          !event.button &&
          !event.altKey &&
          !event.ctrlKey &&
          !event.metaKey &&
          !event.shiftKey &&
          link &&
          link.href.startsWith(location.origin + "/") &&
          link.target !== "_blank"
      ) {
          event.preventDefault();
          navigate(link.href);
      }
  }

There are some points of nuance here where you may want to vary (e.g. the determination of eligible hrefs, and handling of href targets), but this is the bones of it. You can also choose to add more functionality to it. Fastmail’s webmail, for example, uses this basic design, but also handles mailto: links specially (taking you to compose a new email), whitelists path patterns (since the domain is used for more than just the webmail app), and one or two other things.

delaaxe2• 4 years ago

Better use the React root than the entire document

chrismorgan9• 4 years ago

I don’t think the React root is really any better than the document—you should either go precise, or go global, since popstate is global. If there are some links you don’t want intercepted, they’re as likely to be within the React root as without it. See also my response to woojoo666.

woojoo6663• 4 years ago

I think React tends to encourage local solutions (using a Link component) over global ones (inserting a global click handler) when possible. Global solutions are less composable and will cause issues if you have multiple independent teams working on the same page (eg maybe they need different click handlers)

chrismorgan9• 4 years ago

In general I would agree, but as soon as you’re using popstate, you’ve broken that completely: it’s inherently global and will conflict with any other compositions. Because of this, the use of a global click handler will make the application more consistent: either all forms of navigation work, or none; whereas if you use <Link> it gives the impression that you can compose, but the back and forward buttons may be broken.

The History API, as it stands, is global state. That makes it one of the very few places where I say it is better to use a global solution, rather than a precise one.

fatih-erikli• 4 years ago

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:

https://github.com/fatih-erikli/universal-router/blob/main/u...

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

math-dev2• 4 years ago

Interesting - thanks for the tip!

ReactNative228• 4 years ago

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".

Could you explain this one a bit more / maybe some example code I could borrow from? :)

ReactNative228• 4 years ago

Thanks for this!

chrismorgan9• 4 years ago

Please don’t encourage using a single route and the hash; people should just ensure that suitable document is served from all routable URLs—whether it be a consistent bootstrap file, or (generally preferably) that you do server-side rendering. Using the fragment for routing is only something to do when you can’t do it the proper way, not a tool to reach for from the start.

ldd• 4 years ago

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

deckard12• 4 years ago

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

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

Related Stories