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 🙂
The latest version of babel-jest doesn't require `babel-core` with the bridge version anymore (updated in this PR : https://github.com/facebook/jest/pull/7016).
So I'm updating with-jest and with-jest-react-testing-library examples accordingly.
* This is a non-working example of using PHASE_DEVELOPMENT_SERVER and PHASE_PRODUCTION_SERVER in production. I followed @timneutkens gist but was unable to make it work so I've boiled it down into this non-working example which I believe is the same. The README is not updated. Once it is figured out why this is not working, I'll clean up the project and update the pull request to be complete but for now just want to make it work.
* added .eslintrc so that ` eslint . --fix` would work (not sure if that was really necessary). I assume that is same as `yarn lint-fix`.
* fixes for standard style
* fixes for standard style
* Fix example and add some comments
* Updated documentation and small change to logic of prod,dev,staging to work as expected.
Added significantly more doc then I normally would in the hopes that it helps someone avoid the mis-understanding I went through. If it's too much, LMK and I'll reduce.
* removed eslint and updated package.json to get rid of eslint and standardjs
After discussion it was decided instead of rewriting `next/config` and `next/head` imports to `next-server/config` and `next-server/head` we should just allow importing them as `next/config` and `next/head`
Fixes: #6187
