Implement the Singleton Router API

[arunoda]

With this we could easily access the Router via next/router and work with it directly.
Here's a basic example:

pages/index.js

import Router from 'next/router'

const routeTo(href) {
  return (e) => {
    e.preventDefault()
    Router.push(href)
  }
}

export default () => (
  <div>Click <a href='#' onClick={routeTo('/about')}>here</a> to read more</div>
)

pages/about.js

export default () => (
  <p>Welcome to About!</p>
)

Above Router object as an API like this:

• route - String of the current route
• pathname - String of the current path excluding the query string
• query - Object with the parsed query string. Defaults to {}
• push(url, pathname=url) - performs a pushState call associated with the current component
• replace(url, pathname=url) - performs a replaceState call associated with the current component

Usually, route is the same as pathname.
But when used with programmatic API, route and pathname can be different.
"route" is your actual page's path while "pathname" is the path of the url mapped to it.

Likewise, url and path is the same usually.
But when used with programmatic API, "url" is the route with the query string.
"pathname" is the path of the url mapped to it.

Example app is located at the examples/using-router

[arunoda]

Because we don't have the CDN setup, there's no need of using domready.
By the time of this script execution, we can access the __next div.

[coveralls]

Coverage increased (+2.9%) to 60.27% when pulling 20d4eac on arunoda:singleton-router into 955f681 on zeit:master.

[arunoda]

Currently we don't use this anymore.
May be we could remove it.

[arunoda]

Set the default value for url. So, we can access it like Router.push() if we don't change paths with #310

[arunoda]

This is a safe call as React does rendering the same event loop.

[nkzawa]

Is this something we can't avoid ? I want it work fine without any caveats.

[nkzawa]

Hmm, It seems we can't if we keep the syntax.

[arunoda]

But this is fine for React's case. And it's not going to change in the near future. So we are good to go.

[nkzawa]

I noticed this wouldn't work on getInitialProps. I wonder if we should accept this too.

[arunoda]

Use this inside getInitialProps is bad. We need to prevent this or give a fix.
I'll think about something.

Do you have any idea?

[nkzawa]

No :(

Additionally this doesn't work on custom Document (not only on getInitialProps) and custom server too.

[arunoda]

Let's discuss here: #443
I made a solution for getInitialProps. I'll think about inside the custom Document.