Next.js: Params and query data in the router.

[poeticninja]

First of all I would like to say thanks for the exciting work that yall are doing. I really believe in the idea behind Next.js.

I have been testing out the new api that allows for programming links with params and I have some feedback.

In a router there are two basic ways to pass data. Params and the query string. The query string is something that Next.js has had and most recently there has been a merge that allows for parameterized routing. I feel like there is some strange overlap between query and params in Next.js.

I see on the server side we have this line https://github.com/zeit/next.js/blob/master/examples/parameterized-routing/server.js#L21 and you are passing the params as part of the query string. Also on this line https://github.com/zeit/next.js/blob/master/examples/parameterized-routing/pages/index.js#L6 you are passing the params as part of the query string. I feel that these are really two different things but Next.js is using the same mechanism for both.

I almost feel like there should be a ctx object that you an pass into a link and on that object you would have { query: {}, params: {} }.

Example:

<Link href='/blog' as='/blog/first' ctx={{ params: { id: "first" } }}><a>My first blog post</a></Link>

On the server it would be something like :

app.render(req, res, '/blog', ctx)

It just feels strange to pass in params as the query string on the href. Maybe we don't add the props object but instead we simply pass in params and query as prop objects.

Example:

<Link href='/blog' as='/blog/first' query={{ foo: "bar" }} params={{ id: "first" }}><a>My first blog post with a query string of foo=bar</a></Link>

You could also have the query string in the href like before.

<Link href='/blog?foo=bar' as='/blog/first' params={{ id: "first" }}><a>My first blog post with a query string of foo=bar</a></Link>

And the server would be something like :

app.render(req, res, '/blog', query, params)

I just bring this up because semantically they are different but right now link seems to only allow for params to be passed as a query string on the url on the view side. I could be missing something or yall see another way to go about this.

Another thing that feels strange is the href and as. It just seems reversed on what I was expecting. When I was trying to work with Link I wanted the browser to have what was in my href and the as to be what Next.js uses to find the file.

Again I hope this is taken only as constructive and from a positive standpoint. I am really excited about Next.js

[arunoda]

You have some good points.
I think API is freeze for the core <Link /> API.

But you are free to use the underline routing API and build a your own <Link /> component.

(If you do, try to release it to NPM and I hope others might like that too.)

[poeticninja]

Thanks @arunoda for the response!

Unfortunately the current API only allows for the query to be passed into the initial props (client and server). If someone was to build on top of the current API for params they would have to either over pollute the query name space which could cause collisions of params and query. The other option with the current API is to add another level to the object but at that point it would be a very odd developer experience.

Example of the current work around with another level.

static getInitialProps (props) {
  const { query } = props;
  const { query, params } = query;
  return params.id;
}

Without really hacking around this I don't see a good solution. I am not trying to be negative. Just trying to figure out a way this could work in the current direction the new API is going.

[poeticninja]

Maybe rename query to router on initial props and nest query to router.query. I think that would open the current API up to allow for people to come up with their own solutions that are not limited. Then people could attach stuff to router.params... etc.

[rauchg]

@poeticninja what we call params is the query string. The only reason I wanted to be able to pass it to app.render is to avoid double-parsing

[rauchg]

Otherwise, if you're making some decision based on the query string, then you decide what component to render, then next would parse the query string again