Use with React Router 4

[Knaackee]

Is it possible to use next.js with the new react router v4?

[oyeanuj]

@Knaackee Did you try out the possibility? I am wondering as well if someone has gotten it to work with any version of RR?

[sergiodxa]

Next has his own router, why use RR?

[oyeanuj]

@sergiodxa Weighing options as I port my existing app to Next. I have a static, nested route config working and wondering what can I keep using, and what not..

[sergiodxa]

@oyeanuj 🤔 you can gradually migrate to Next, just set Next.js to handle 1 route and use a proxy to have both your current app and the Next.js one, then move a second route from RR to Next.js, and that way you can keep your current app while migrating, eventually you will have everything in Next.js

[igl]

From looking at the examples it seems that next has a single route table like RRv2-3 and does not support "nested routes" like RRv4. These are nice.

I would try to use RR or is there a big caveat i don't know about?

[mrwillis]

@igl Have you figured out a solution to that?

[jcheroske]

The new react-router 4 paradigm of nested routes is a game-changer, and is something of a must-have in our current project. I'm wondering if anyone has succeeded in getting rr4 to work with next.js?

[malixsys]

MemoryRouter does work, if not as intended... Otherwise, dynamic components can be client-side only, where HashRouter works fine...

const AdminPage = dynamic(
  import('..../AdminPage'),
  { ssr: false }
);

[pegiadise]

I 'm also following @malixsys approach and handling client side routing with react-router and all the server rendered content with next router.

[dennis-b]

@malixsys @pegiadise can u please give some more details how to use next router and react-router together ?

[pegiadise]

You can set a flag in componentDidMount and conditionally render the <Router /> when the flag is truthy. (componentDidMount does not run on server 😉)

[jaydenseric]

In fact, we're incorporating React Router inside Next.js soon :) — https://twitter.com/rauchg/status/948318111828099072

[JonCognioDigital]

Is this still happening? I can see the release notes for V6 canary and there is no mention of it.

[timneutkens]

Eventually. It's definitely on our minds. We've got other priorities right now (layout component, reliable development and a few other long standing open issues).

[JonCognioDigital]

That is a shame, it might be low priority for the team but it's basically the only thing stopping people like me from starting to use it. I read your tutorial until I got to the bit where it said that routes have to be set up twice then gave up.

[willopez]

@timneutkens adding react router integration would help increase nextjs adoption and make development better. Devs like myself would love to see this happen, please consider increasing the priority.

[romainquellec]

That is a shame, it might be low priority for the team but it's basically the only thing stopping people like me from starting to use it.

Same.

[benkingcode]

Can we at least re-open this issue so it can be tracked?

[timneutkens]

I'm going to reopen this, but note that this is an open source project and we don't have a very strong case for it at this moment for zeit.co, since we use Next.js for everything.

This is why I was saying it's part of the longer term goals and can't be implemented immediately, but we're working towards it.

The features I've been introducing in Next 6 are actually working towards React Router support.

We had other priorities for Next 6, which are tremendously improving Next.js's reliability and scalability, for example 100x faster page resolving, App Component, making next export work in development, babel 7, etc.

I hope this elaborates on my earlier comment.

So the TLDR is:

• We're going to do it, but not immediately
• Next 6 has many improvements to different parts of Next.js

[rauchg]

To further extend @timneutkens's comment: we definitely want RR, but we don't have any pressing limitations in the current Router that make it a priority. All the routing use-cases you can imagine have been implemented successfully with the current Next.js API

There are two reasons we really want React Router support for:

• Simplify our own Next.js codebase, not have to maintain our own router, make things smaller and modular
• Simplify the migration path of large applications already using RR

As such, I agree we should keep this issue open!

[merrywhether]

As a counterpoint, not having react-router means that next works nicely with relay-modern and was one of the reasons we switched to next from our old react-router app.

[igl]

@merrywhether I worked on an RRv4 app with relay-modern last year. Care to be more specific? I don't remember us having serious issues because of either.

[merrywhether]

@igl This is according to relay's documentation: https://facebook.github.io/relay/docs/en/routing.html#react-router-https-reacttrainingcom-react-router

The problem is that RRv4's component approach doesn't allow for determinism during the pre-compilation step, which can result in request waterfalls in the client.

[benkingcode]

@rauchg Out of interest, my understanding of Next's router is that it doesn't support the concept of nested routing, so you can keep outer markup while navigating within a page. Do you know if there is a way to make this possible with the current router?

[sergiodxa]

@dbbk check our nextgram example app (https://github.com/now-examples/nextgram), it does exactly that

[merrywhether]

In next 5, we're accomplishing "outer markup" by having top-level layout components that all of our pages extend: base layout has top nav, then a few sub-layouts that extend base for lists/details/etc, and then our pages components extend these sub-layouts with their own specific content. In next 6, you could also accomplish basic "outer markup" using _app.js I believe.

[srallen]

Will the next version be configurable to choose a routing solution that is not React Router?

[kontopro]

Hi, i only need react router in order to pass props to pages (using <Route render ={} /> instead of <Route component ={} /> ), can i do it with Next?

[vjpr]

See https://github.com/zachrbrown/next-react-router. There are scarce docs atm, but some brief explanation in https://github.com/zachrbrown/next-react-router/blob/master/src/IsomorphicRouter.js.

[7c78]

From looking at the examples it seems that next has a single route table like RRv2-3 and does not support "nested routes" like RRv4. These are nice.

Hi,

Does this mean I have to create a single page for a single route?

Let say if I have 2 routes sign up, log in. I would have 1 page that shares the same layout, the only difference is area of forms. That is I just need to create 1 file in pages folder. But with next routes I have to create 2 files in pages folder. Is it?

If it is, then the layout is is remounted with every navigation, not just forms area, right?

[7c78]

https://github.com/zeit/next.js/issues/75

[merrywhether]

@7c78 One thing you can do is leverage _app.js for persistent page layout for all pages. The other thing to do is to create shared layout components that you can reuse throughout various pages in order to achieve what you are looking for:

// pages/login.js

class LoginPage extends React.Component {
  render() {
    return (
      <AuthForm>    // same component can be reused in signup
        <form>
          ...implementation of login
        </form>
      </AuthForm>
    );
  }
}

Additionally, you can do what we've done recently and define base layout components that your page components all extend:

//layouts/baseAuth.js

class BaseAuth extends React.Component {
  abstract formContent();  // we use typescript, but you can have the same concepts
  abstract formSubmit():

  render() {
    return (
      <SomeStyledDiv>
        <form>
          {this.formContent()}
          {this.formSubmit()}
        </form>
      </SomeStyledDiv>
    );
  }
}

And then you just extend BaseAuth in your login and signup pages and define formContent and formSubmit in each of them (these are toy examples, since I don't know you exact requirements).

[7c78]

@merrywhether I currently use your approach, and next examples use it too.

But my concern is I need to create separate pages for separate forms. That is layout is reused but not page. And the layout is is remounted with every navigation.

With RRv4, we have single page and forms are rendered/remounted based on routes (not the whole page). Routes are just components.

Thank for fast response!

[merrywhether]

@7c78 That's true about remounting, though I do think the DOM nodes are re-used as the vDOM resolves to the same state.

It's not something we've been super concerned with because we also can't use react-router with relay-modern, so we've had to use this pattern regardless.

[7c78]

@merrywhether I am not sure about vDOM because server returns new document/html for every routes. Sorry, ignore this assumption, I am just a newbie.

I agree that we have to use this pattern anyway. Thanks!

[rovansteen]

You can use RR with next.js by having your whole app be in the pages/index.js but you lose some of the goodies of next like out of the box code splitting and have to set that up yourself.

[disintegrator]

I would love it if Reach Router was considered. It's very similar to react-router and brings some important benefits:

• It solves some important a11y concerns around link generation and focus management (https://reach.tech/router/accessibility).
• It weighs less (at the time of writing)
  • @reach/router@1.1.1: 18.7 kB / 6kB (link)
  • react-router-dom@4.3.1: 44.1Kb / 10.4kB (link)

[romainquellec]

Reach Router is also great 🥇

[AndrewIngram]

RR-style dynamic routes are a nice API, but static (and statically analysable) routing brings a lot of benefits too. Neither approach is a slam-dunk winner.

[zenflow]

@sorokinvj That's only supported via a plugin (currently) .. https://github.com/fridays/next-routes

[williamli]

static links are so basic that it doesn’t even support parameters in links...

i am using a third party package next-routes for now https://github.com/fridays/next-routes to get around it

Sent from my iPhone

On 24 Oct 2018, at 23:01, Andy Ingram notifications@github.com wrote:

RR-style dynamic routes are a nice API, but static (and statically analysable) routing brings a lot of benefits too. Neither approach is a slam-dunk winner.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[merrywhether]

We're using next-routes as well for the time-being, but I believe the next team is working on adding path parameters to their file-system routing via regex file names (inspired by Sapper).

[curran]

@merrywhether I'm using next-routes as well but would prefer this be part of Next.js core.

You mentioned

I believe the next team is working on adding path parameters...

I'm curious do you have any reference for this? Perhaps an open issue for route parameters? I'm not able to find one... Perhaps the plugin solves the need and that will be the recommended solution going forward.

[merrywhether]

@curran The source was a tweet from on of the sapper.js devs, saying that next was taking inspiration from sapper.js and implementing regex-filename-routing in a future version. Of course, Twitter being what it is, I could not for the life of me find the original tweet.

[TrejGun]

This issue was raised on Apr 5, 2017 and now is Feb 27, 2019. Almost 2 years and no solution May be its time to replace half-assed built-in router with something good?

[curran]

Ouch. That's quite insulting to NextJS devs who put many hours into the routing solution.

[ivan-kleshnin]

I missed ReactRouter at first. Now I don't even remember NextJS has a different Router until someone reminds me. Verbose Link API is trivial to wrap with proxies (depending on your data/API architecture), for example. Sharing this top secret: 😆

import _Link from "next/link"
export function Link({as, children, href}) {
  as = as || QS.parse(U.parse(href).query || "").url || null // QS, U are parsing libs
  return <_Link as={as} href={href}>
    {children}
  </_Link>
}

<Link as="/about" href="/page?url=/about"/> verbose
→
<Link href="/page?url=/about"/> ok

I think we all should spend less time complaining about secondary stuff 😉

[ceddybi]

@ivan-kleshnin Nice i added a similar wrapper

[timneutkens]

As per previous comment I'd like to point to https://www.contributor-covenant.org/version/1/4/code-of-conduct

I've hidden said comment.

[revskill10]

I have no problem with next/router for most of use cases. But it should improve a bit on the universal routing part. In case of Now 2 deployment, i'd love to just take now.json and use it to route in my application.