HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
remix-run
react-router
TypeScript2014–2026
remix-run / react-router

react-router

Declarative routing for React

52Distinct people
59Mentions
1Explicit recommenders
56.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Declarative routing for React

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

(Marginally related rant) I love React, but so far I've been a bit underwhelmed by the ecosystem of components that has sprung up. I hope that this site will help. A lot of the…

skrebbel used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year59 dated mentions

Observed mentions: 2014-06-21 17:19:45 UTC to 2026-04-08 21:17:27 UTC.

0369122014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 10 mentions; 3 submissions, 7 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 10 mentions; 3 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC1019
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC1037
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC1037
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC12111
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC505
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC211
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

12 sources
Universal web components are a pipe dream. Even within a community using the same framework or library, there is disagreement on how to solve certain problems. For example, the folks behind React Router removed parsing of querystrings, because people wanted the flexibilty of using alternative solutions [0]. It's hard to imagine something more trivial than parsing querystrings, yet no consensus exists among users of the same library (which itself is not officially-sanctioned by FB yet, and even React, while stronger than other libraries, is not loved and used by all client-side web devs) on how to do it best. Yet people think someday in the near future, these differences will just disappear magically, and we will be able to author web components that snap--like Lego bricks--into whatever environment a developer wants? [0] https://github.co
Read the rest
In Marko – An isomorphic UI framework similar to Vue
Upgrading from 3 to 4 is not required. Version 3 is still maintained. It's not ideal since there will probably be no future major 3 versions, but no one is forced to make a 'big breaking change' strictly speaking. > We intend to keep supporting the 3.x branch indefinitely (published separately on npm to aid in migration), although there will likely not be any future major versions based on that code. 4.0 is the future, but we won't leave you hanging if you want to stick with 2.x/3.x. https://github.com/ReactTraining/react-router/releases/tag/v... Previously discussed here: https://news.ycombinator.com/item?id=12511419
In Webpack 3: Official Release
I'm not a fan of React Router but this sounds like you haven't actually used any of those versions or even looked at the breaking changes. Here's what actually happened: v1: https://github.com/ReactTraining/react-router/blob/v3/upgrad... v2: https://github.com/ReactTraining/react-router/blob/v3/upgrad... v3 mostly just removed APIs that were deprecated in v2. v3 continues being maintained even beyond the v4.0.0 release. v4: https://github.com/ReactTraining/react-router/blob/master/pa... In my opinion it would have been clearer if react-router v4 had been released under a different name but I guess the authors didn't want to pay the cost of that. The API changes between 1 and 2 as well as 2 and 3 are mostly cosmetic. It's worth pointing out the authors released codemods which will likely be able to convert your app from one version of the
Read the rest
library to the next as long as you don't do something exceptionally clever. The changes between 0.x and v1 were entirely expected. It seems the authors followed the common semantics that 0.x releases are considered experimental, v1 was based on the lessons learned. v2 and v3 then improved upon that design with relatively minor changes. On the other hand v4 is an entirely new library using an entirely different paradigm: routes use component semantics and are part of the component structure, rather than just some JS router that uses JSX syntax for aesthetics. But as I said: v3 is still being actively maintained, the authors have just decided that the v4 API fits React better. And for all major releases from v1 to v3 you should be able to upgrade practically for free by using codemods. I think the importance of codemods can not be understated though many people are still ignorant of them: Facebook releases codemods for every major version of React and uses them internally to upgrade their tens of thousands of components automatically. Third-party libraries like React Router have also started providing them. Codemods written well should allow app developers to migrate breaking API changes in dependencies with practically no development effort. Additionally, like React, React Router seems to have adopted the approach of deprecating APIs in the final release of a major version that is no longer going to be supported so you can upgrade your manually code before moving to the new major version with no fear of things breaking. So when upgrading from v2 to v3 you should be able to upgrade safely by simply upgrading to the latest minor version and fixing any deprecation warnings. Both codemods as well as deprecations of course assume you're doing the sensible thing and a) upgrading one major version at a time and b) actually maintaining your project rather than just spending half an hour on it once a year to implement a new feature with no test coverage. Personally I often end up doing the not so sensible thing where I end up having to migrate all third party deps to the latest version once a year or two, but libraries like React and React Router are the least of my worries because they are extremely safe and easy to upgrade -- even to the point where there's no need to upgrade beyond React Router v3 unless you also prefer the v4 API.
In Switching From React To Vue.js
If you use React with react-router[0] (or a comparable JS-based solution), you can just apply lz-string[1] to a stringified JS object and make the resulting string match a path. Then you need is some code to reverse the operation (lz-string -> JSON -> JS object). That's what I'm doing to create shareable state in an app I'm building for a research group. Done naively, it will have the same problems others mentioned here: it barely shortens the URL. However, in the case of my specific app - a browser for data sets for single cell RNA sequencing - the state is largely dependent on the data set being viewed, and the data set is unchanging. What that means is that we can "externalise" the data being referred to, to pre-transform my JS object (which is an object tree) to nested arrays with integers (so a kind of "array tree") that use the data
Read the rest
set as a look-up to reverse the operation. The latter is already a lot shorter when stringified, but also more compressible: the character set is limited to ten digits, commas and square brackets, and different values may be transformed into the same numbers, being distinguished by their position in the array tree. To make this operation easier, I created a few helper functions to declare a "schema" that creates a recursive function for transforming the original JS object to said array of arrays, and vice-versa: https://gist.github.com/JobLeonard/a47692a1f77bebc06c2518f32... As you can see in the gist, that transformation shrunk a URL of 2466 characters down to a (admittedly still crazy) 638 characters. I was thinking on putting it on NPM but it looked so specific in its applicability that I haven't bothered turning it into a proper package yet. [0] https://github.com/ReactTraining/react-router [1] https://github.com/pieroxy/lz-string
In Show HN: Shortern URIs using Huffman Coding, not a database
React Native is a popular method for creating semi-native, JavaScript-based iOS and Android apps, based on the very popular React library. There's no one standard routing/navigation library in the community. As that's quite an important part of almost every app, a new high quality solution is something that any React Native dev would be interested in. I'm sure you know who AirBnB are. They've spent the last year (?) building part of their mobile apps with React Native, and this is their home-grown navigation library. Now, most React Native components (including navigation libraries) are built almost entirely in JavaScript, but this one is one of a few which "bridge" the native iOS and Android APIs, potentially resulting in a more natural and familiar feel. There's one other semi-native nav option out there, Wix's React Native Navigation[1
Read the rest
]. I've not personally tried either of them, but it's nice to have choices. There are lots of JavaScript-based routing systems out there. React Navigation[2] is the closest we've got to an officially sanctioned package in a while, being the successor to two very popular libraries (Facebook's own NavigationExperimental[3] and Exponents Ex-Navigation[4]). There's also React Native Router Flux[5], which is quite popular, and the very popular React Router[6] has support for React Native in their recently released v4. As you can see, there are quite a few options available, and there are even more if you want to delve deeper[7] [1]: https://github.com/wix/react-native-navigation [2]: https://reactnavigation.org/ [3]: https://github.com/facebook/react-native/tree/master/Librari... [4]: https://github.com/exponent/ex-navigation [5]: https://github.com/aksonov/react-native-router-flux [6]: https://github.com/ReactTraining/react-router [7]: https://js.coach/?search=navigation
In React Native Navigation Library
The code that does this for server-rendered js is in https://github.com/ReactTraining/react-router/blob/master/mo.... There's code to convert URL patterns to regular expressions in https://github.com/ReactTraining/react-router/blob/master/mo..., although that seems to work only for a single pattern and not all. Presumably you should find a way to convert all patterns to a single regex somewhere in the codebase and could use that to check the request in go.
In Go 1.8 Release Notes

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.