61–70 of 90 posts
We migrated from React Router to Reach Router ( https://reach.tech/router ) and found it to be better in a few ways: * Built-in focus management. * Smaller library size. * Implicit route matching that Just Works. * More comprehensive docs with live examples. Migration was easy. Highly recommended.
Earlier quoted context omitted.
> The solution to the external links issue is a one-liner. It is most definitely not a one-liner. > Making the page scroll to the top when navigating to a new page is trivial. So do it for me. There’s no reason a routing library should break default behavior. > That's exactly what it's supposed to do. It's a client side routing solution. (I'm also pretty sure that it doesn't remount) Then it’s “supposed” to have inco…
> So do it for me. I think this will work: Put this wherever you put your reusable functions: `const scrollToTop = () => document.getElementById('root').scrollIntoView();` And put this in the components / functions you want the scrollToTop effect to work on: `useEffect(() => { scrollToTop() }, []);` And put this in your CSS: `html { scroll-behavior: smooth }` (Edit to add: Not saying React Router is something you sho…
"Scroll Restoration" https://reacttraining.com/react-router/web/guides/scroll-res...
I've never been a fan of React Router (mostly I don't get why defining routes with components is a good thing) and have been pleasantly surprised with how well Curi ( https://curi.js.org/ ) works. It's nice to see it's not completely tied to a JS framework.
> I don't get why defining routes with components is a good thing It makes the routes reactive. This is not necessary for smaller projects, but where it is needed this can be really helpful. The responsive route example shows this off well https://reacttraining.com/react-router/core/guides/philosoph...
We migrated from React Router to Reach Router ( https://reach.tech/router ) and found it to be better in a few ways: * Built-in focus management. * Smaller library size. * Implicit route matching that Just Works. * More comprehensive docs with live examples. Migration was easy. Highly recommended.
So both of these routers are written by Ryan Florence? Interesting, what was the reason behind this? Freedom to experiment in one repo while keeping the other stable?
FWIW, I use Reach Router for everything now and greatly prefer it.
Earlier quoted context omitted.
Yup. I only use react-router when I have to (work). My other projects I always roll my own. A typical html5 push router can be really small. I don’t reinvent the wheel normally but routing is hugely overcomplicated in the react ecosystem.
I feel like part of the problem with react libraries is that they implement their code "the react way" which basically means forcing it into your tree hierarchy. Dealing with dozens of higher order components gets really annoying after a while.
Before we had one hierarchy where everything was a component, logic and visuals.
Now we have two hierarchies where visuals are components and logic are hooks.
I migrated away from react-router because from v3 to v4 broke everything that made sense. Things became wildly more complicated. I'm now extremely happy with my new router of choice router5 (not to be confused with React Router 5) https://router5.js.org .
We migrated from React Router to Reach Router ( https://reach.tech/router ) and found it to be better in a few ways: * Built-in focus management. * Smaller library size. * Implicit route matching that Just Works. * More comprehensive docs with live examples. Migration was easy. Highly recommended.
I get the sense that Reach Router is no longer maintained despite what the project owner says, plus there's the fact that he's been rehired into the React Router team.
Something about HN gives people license to air all of their nitpick grievances, and make it seem like SUcH A bIg DEaL OmG WorST LiBRarY EVArR!11
To the authors, maintainers, and contributors: Thank you for making the ecosystem better. It makes our work easier.
Using react router on one of my personal projects (~ 30k loc) was probably one of my largest regrets. At every turn it seemed designed to do the thing I wouldn’t expect, or have arbitrary restrictions that made my life tougher. Some examples: * there's no relative routes https://github.com/ReactTraining/react-router/issues/2172 * there's no way to refresh the page https://github.com/ReactTraining/react-router/issues/…
* Relative links are supported out of the box. If you use '..', it is relative to the current "directory" (i.e. it ignores any trailing slash)
* Navi allows you to reload the current route using `navigation.refresh()`. This is undocumented as I didn't realize that it is a feature people actually need, although I'd be happy to document it in a future release after making sure that the behavior makes sense.
* Navi handles scroll-to-hash and scroll-to-top automatically (and you can disable it by passing a prop)
* The component works for external links automatically.
* Navigating to the same page does not reload the page, but you could implement this by creating a wrapper around , and calling `navigation.refresh()` if the link points to the current page.
And while it's not specifically one of your pain points, Navi also works server-side and has an in-built static build tool for SEO – which is probably important given the features that you're looking for.
While it's easy to say "just don't do client-side routing", there are a growing number of sites where client-side routing makes sense. I saw that you're making a music site, and client-side routing definitely makes sense. I'm building content for teaching React/Frontend Dev, and the live editor loads a lot of files that should be cached between pages, so client side routing also makes sense (and besides, it's just so much faster).
Would love to hear any feedback on the tool :-) Here's the URL: https://frontarm.com/navi/en/
This is going to be awesome for React's apparent main industry: Training. A new set of videos and code camps...