Next.js: Route definition in page files

[pragmaticivan]

Feature request

Is your feature request related to a problem? Please describe.

Would be nice to define a route with params inside the page file instead of defining it in the server file.

Describe the solution you'd like

The file would have a reserved export route that should be an Object.

import React from 'react'

export const route = {
  path: '/products/:id',
  method: 'get',
};

export default class extends React.Component {
  static async getInitialProps({ req }) {
    const id = req.params.id;
    return { id }
  }

  render() {
    return (
      <div>
        Hello World {this.props.id}
      </div>
    )
  }
}

or

import React from 'react'

export default class extends React.Component {

  static route = {
    path: '/products/:id',
    method: 'get',
  };

  static async getInitialProps({ req }) {
    const id = req.params.id;
    return { id }
  }

  render() {
    return (
      <div>
        Hello World {this.props.id}
      </div>
    )
  }
}

Additional context

That would keep development simple when you need url params defined.

[seanconnollydev]

The static route definition fits well with the current framework (it doesn't compromise code splitting like react-router or other routers out there). I rather like keeping the route definition local to the page that will serve it because it makes the impact of code or route changes more obvious.

req is a server only parameter in getInitialProps so I don't think you can pass the params along with it. An alternative would be to pass params as a separate property or to merge them with query, which is how next-routes works.

A few downsides to this approach:

• No clear way to control resolution order
• Loading all routes requires loading all page files. This might conflict with next's just-in-time compilation in dev mode.

[pragmaticivan]

I'm not very familiar with the core implementation of the framework, but I assume the default routing system based on pages does just the same thing, it creates routes based on the filename. Adding a route constant or even defining it as a static attribute of the component just like getInitialProps would be reasonable the current implementation as it will be just overwriting the routing.

getInitialProps for instance, already receives req (ex: https://github.com/zeit/next.js/#fetching-data-and-component-lifecycle) I don't think there is nothing new here.

About the next just in time compilation, I agree, seems to be a problem.

Thanks for taking the time and taking a look at this @goldenshun !

[seanconnollydev]

Read further in the docs for getInitialProps and you'll see this:

req - HTTP request object (server only)

[pragmaticivan]

For the initial page load, getInitialProps will execute on the server only. getInitialProps will only be executed on the client when navigating to a different route via the Link component or using the routing APIs.

Not sure what would be the issue here. When navigating via client, this becomes a XHR request, right?

[seanconnollydev]

No, req is undefined when navigating on the client. What xhr request would it be?

[pragmaticivan]

Just maturing out ideas. What if:

When navigating to a route, if the request is application/json type, it will automatically make a request to getInitialProps of the component and handle it as a server.

static async getInitialProps ({ req, query }) {
    const isServer = check if is server here
    // Can be used to avoid using libraries that only can be performed on nodejs.

    return { item: query.itemData }
}

Ex:

SSR

If you hit a route in the browser, it will request as html response, and will server renderer the component, which will get the state of getInitialProps in the server.

SPA

If you navigate to another page using Link it will load the chunk of the component, and make a XHR Ajax request to the getInitialProps as server route that should return the state for this next component to be loaded, so in the client it applies the props coming from this async request to the component.

Do you see any problem with that?

[seanconnollydev]

Now you lost me @pragmaticivan. What problem are you trying to solve with all of that?

[pragmaticivan]

The first one in the task. Defining a routing system in the component Page without needing to defining it using a server file, and be able to manage the initial props on SSR + SPA using relatively the same code.

[revskill10]

I think this is easily solvable with a HOC. No need to implement this in the core.

[timneutkens]

Closing this as #7607 has landed.