wrapping `startClock` in `bindActionsCreator` there's no need to pass `dispatch` in:
```
this.props.startClock(dispatch)
```
Furthermore `bindActionsCreator` is not needed because following already bind actions:
```
const mapDispatchToProps = {
startClock
};
```
* Add support for .amp.js pages and
resolving /page?amp=1 to page.amp.js
* Update amp tests
* Update example and clean up amp page resolving
* Add nested amp test
* page => normalizedPage
* Add type to page options
* Add handling of amp with all pageExtensions
and normalize page
* Make sure findPageFile only falls back to
amp if enabled
I noticed that the nodemon.json file was not watching for all file changes in the correct location for filetype .ts (typescript). After some research I found that the "ext" option in the nodemon.json fixes the issue and should work across all operating systems.
Replicates the behaviour of the `with-mobx` example but implemented using `mobx-react-lite` and React context.
I'm still working out a best practice regarding actions and welcome feedback on anything.
* Typecheck server vs. client code independently, ensuring that each respects its own tsconfig.
* Use nextjs default distDir in tsconfig
* Update packages
* Fix type error in server.listen callback
### changes
#### remove trailing spaces
When I was using example I noticed trailing spaces.
So, this PR removes the trailing spaces of json file, README, and others.
`examples/with-jest-typescript/src/modules/cars/Overview.tsx` also has it, but this time it did not change as tslint error occurs at commit.
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).
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.
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
Next.js no longer uses `jsonPageRes`.
This PR removes it from `en-us` and `zh-cn` documentation (formatting picked up some changes on zh-cn readme).
Also updated the Flow type def for `getInitialProps`.
Resolves#6363
[React ESI](https://github.com/dunglas/react-esi) is a brand new cache library for vanilla React and Next.js applications, that can make highly dynamic applications as fast as static sites by leveraging the open Edge Server Include specification.
https://github.com/dunglas/react-esi
Because this spec is widespread, React ESI natively supports most of the well-known cloud cache providers including Cloudflare Workers, Akamai and Fastly. Of course, React ESI also supports the open source Varnish cache server that you can use in your own infrastructure for free (configuration provided).
This PR shows how to integrate React ESI with Next.js.
