Electron recommends to disable nodeIntegration in BrowserViews.
This PR follows this recommendation and updates the example accordingly.
Changes:
- disable nodeIntegration
- update dependencies
* Rename page component's class name: Counter => Index, Counter => Other
* Rename counter component class name: AddCount => Counter
* Add counter actions `decrement` and `reset` same as with-redux example
* Modify page link by NavigateTo attr in Page component
* Modify license MIT => ISC same as others in package.json
* Modify README
fixes#4390
* Installing only `babel-plugin-transform-decorators-legacy` didn't work
* It also needs to install `babel-plugin-transform-class-properties`
It's better that Counter behave not only `increment (add)` but also `decrement` or `reset`.
* Add decrement, reset handlers and rename add handler in `components/counter.js`
* Add increment, decrement, reset actions to `store.js`
* Rename page component class name: Counter => Index in `pages/index.js`
* Remove needless dispatch count event on getInitialProps in `pages/index.js`
* Format JSX to be readable in `pages/_app.js`
* Remove needless line from `components/examples.js`
* Remove needless spaces in `lib/with-redux-store.js`
The option `"decoratorsLegacy": true` seems mandatory, fails without it:
> The new decorators proposal is not supported yet. You must pass the `"decoratorsLegacy": true` option to @babel/preset-stage-0
Fixes the compilation error :
```
* ./clock in ./components/examples.js
ModuleNotFoundError: Module not found: Error: [CaseSensit
ivePathsPlugin] `/components/clock.js` does not matc
h the corresponding path on disk `Clock.js`.
```
This example gave me 404s on `pages/*.tsx` when using it with the latest nextjs (`5.1.0`) and `@zeit/next-typescript@0.0.11`. The latest next-typescript plugin version fixes it.
* Add new apollo example
* Update readme
* Update with-apollo to use _app.js
* Move withData to _app
* Make SSR work again
* Remove withData
* Use HOC to provide apolloClient
* Spread pageprops
When running some tests, I noticed that Akamai was still caching the
response for render errors for some reason. Honestly, I would've
thought that `no-store, must-revalidate` would be enough to prevent
the CDN from caching it.
That being said, MDN's documentation on [Cache-Control] has a section
called ["Preventing Caching"] and recommends also using the `no-cache`
directive.
Given the definitions provided for `no-cache` and `no-store`, I can't
tell much of a difference between these two. But I _do_ know that,
for whatever reason, Akamai seems to respect the `no-cache` value for
this header.
[Cache-Control]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
["Preventing Caching"]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#Preventing_caching
