* Update to use the correct router instance in withRouter so error is
thrown when router method is used during SSR
* Revert changes to with-router and add error to methods on
direct router instance
* Extend Router and override methods with error instead
* Update ServerRouter, add err.sh, and add test
Thanks so much for putting this amazing framework together!
I was reading through the docs and noticed how `an URL` was a little awkward to read. This is an incredibly small update to the readme to change the wording to `a URL`.
Playing with this example, I realized that it was not doing what I expected in case of an error coming back from the API (e.g : throw properly the error and save it in the state).
* Add warning on stalled page load possibly from too many tabs open
* Add test for stalled warning
* Update onDemand pinging to close on routeChangeStart and added
warning when onDemand handler detects multiple tabs from the same
browser
Adds an example app using [graphql-hooks](https://github.com/nearform/graphql-hooks) that started life as the with-apollo example app. It uses the same graph.cool backend, mostly to demonstrate how similar it is.
* Show error when `router` or `Component` are returned in _app.js
getInitialProps
* Update to only show error in dev mode
* Update packages/next-server/server/render.tsx
Co-Authored-By: ijjk <22380829+ijjk@users.noreply.github.com>
* make router UrlIsNew comparing method work as expected
* Remove shallow-equals from router and update urlIsNew check
* Remove shallow-equals test since it is no longer used
* Add integration test for asPath query
Hello,
I have been using next.js for a while in a bunch of projects, so first for all thanks for all the vibrant effort around the project 🖤.
Always I see the server side next.js approach as an advantage, but also a weakness for the extra resources you need to have, specially comparing how cheap is a client side app.
In order to do my things cheaper, I started using the SSR pattern you suggested in your examples, so useful! It saves time and resources.
However, it was *too simple*. In a real production scenario, you need a bit more, specially related with send the right response headers to keep the rest of external network agent updated of your cache state.
I started a tiny script code for doing that; basically, I copy/paste it on my ssr projects.
Now, after a time, I think it's worth it publish it as [cacheable-response](https://github.com/Kikobeats/cacheable-response) module.
The PR is for adding the module leverage into the next.js ssr example.
It's doing the same, plus:
- be possible use a multi storage cache (memory by default; mongodb, redis, mysql, supported).
- sending `cache-control` response headers.
- sending `X-Cache-Expired-At`, just a humanize way to see the expiration time.
- support for forcing invalidation via `force=true` query parameter.
I hope you like it 🙂