On the server `props.initialMobxState` received by the `constructor` is a fully functioning mobx store that was instantiated by `getInitialProps()` only a few ticks earlier.
Thus, creating a new instance is unneccessary.
In the browser, however, `props.initialMobxState` is a hydrated plain object and thus the store needs to be initialized.
Current with-ant-design-less example has some problems.
- Upgrade next7, console found a 404 error.
> After upgrade next7, .next folder didn't find /static/style.css and there is /static/css/style.chunk.css.
- The /_next/static/style.css link don't need be placed in the <Head> tag. The style.chunk.css file will be add in the head tag automatically after build.
- The project with more pages include _app.js, _document.js...the antd-custom.less will not work well.
> The solution is use `modifyVars` of `lessLoaderOptions`. It work well in my project~
Instead of bundling `postcss-cli` we can now make use of `@zeit/with-css`.
This also means we can get rid of the `<style>` import and concurrent build step for css. 🎉
- use `enhanceApp` so that styled-components used in _app.js are server rendered
- call parent getInitialProps, fixes#5629
- return `styles`, making the render() method obsolete.
cc @mxstbr @probablyup
I spent far too much time fiddling with this example project before realizing it contained a bug in the store initialization logic and it was a bit more complex than it needed to be.
* The custom server was not needed
* The store-initialization did effectively the same thing twice for no reason
* And wrapping MyApp component in a HOC was wholly unnecessary indirection
My changes are split into four discrete commits for clarity.
* added example for using typings-for-css-modules-loader
* Update examples/with-typings-for-css-modules/README.md
* Update examples/with-typings-for-css-modules/README.md
* Update examples/with-typings-for-css-modules/next.config.js
- Looks like no other example provides a link to a hosted demo
- There is the "Deploy to now" badge, so it can be deployed on demand when needed
- The link is broken anyway
- Probably any example hosted by an individual contributor sooner or later will be cleaned up, doesn't feel like a reliable way to provide a live demo
package accept returns false if can't find language in offered list of languages, then later on
bool is attempted to be split, and app crashes in prod & dev
Docker Multistage
* Remove `devDependencies` from `./node_modules`
in `builder` for faster copy on `base` init
* Added `isomorphic-unfetch` to show it not
being copied over to `base`.
* `isomorphic-fetch` will still show from `next`
I successfully deployed this example with `now` and `now --public` (I am on premium plan).
Did this before deploy
```sh
$ cp Dockerfile.multistage Dockerfile
```
The mobx-state-tree examples (with and without typescript) pre-dated the next _app class and needed to be updated to use _app for persisting state across client-side navigation transitions. Also removed unneeded custom server class to better keep with the "show one feature per example" style of the next examples folder
Fixes#5352 . This updates the example updating react-i18next to v8.0.6, replacing the `translate` HOC to `withNamespaces` and `I18n` to `NamespacesConsumer`.
There is one thing that I am not sure if is correct or not so I need some guidance. You gotta wrap the page with the `withI18next` HOC so it will extend the `getInitialProps` of the page with this:
```
Extended.getInitialProps = async (ctx) => {
const composedInitialProps = ComposedComponent.getInitialProps
? await ComposedComponent.getInitialProps(ctx)
: {}
const i18nInitialProps = ctx.req
? i18n.getInitialProps(ctx.req, namespaces)
: {}
return {
...composedInitialProps,
...i18nInitialProps
}
}
```
The problem lies in `i18n.getInitialProps` that has this code:
```
i18n.getInitialProps = (req, namespaces) => {
if (!namespaces) namespaces = i18n.options.defaultNS
if (typeof namespaces === 'string') namespaces = [namespaces]
req.i18n.toJSON = () => null // do not serialize i18next instance and send to client
const initialI18nStore = {}
req.i18n.languages.forEach((l) => {
initialI18nStore[l] = {}
namespaces.forEach((ns) => {
initialI18nStore[l][ns] = (req.i18n.services.resourceStore.data[l] || {})[ns] || {}
})
})
return {
i18n: req.i18n, // use the instance on req - fixed language on request (avoid issues in race conditions with lngs of different users)
initialI18nStore,
initialLanguage: req.i18n.language
}
}
```
In my understanding, among other things, it gets the `i18n` object from the request (included by the `server.js`) and uses the data to create `initialI18nStore` and `initialLanguage`, and then return these two objects plus the `i18n` object itself. If you add the `i18n` object on the return, then there will be a crash on the client-side render of the page:
```TypeError: Cannot read property 'ready' of null```
I don't know why, but returning it breaks `NamespacesConsumer` component from `react-i18next` (the state becomes null). So I commented this line and the provider on `_app.js` is getting the `i18n` instance from the `i18n.js` file (the same as `server.js`). I don't know if this would be an issue so I would like help to debug this.
Regarding a question about having different global layouts via `_app.js` usage, it came up that we could use a static property in the page that needed a different one(Thanks @timneutkens )
Link to the Spectrum post: https://spectrum.chat/?t=af6ca794-5420-4780-abd8-96f085a19e09
This PR adds an example called `with-dynamic-app-layout`, that showcases that use case in the simplest way I could think of.
Let me know if there's changes or improvements to be made. 🎉
* Add analyze-bundles example
* housekeeping: with-webpack-bundle-analyzer example
* analyze-bundles example: revert the version of faker library
* analyze-bundles add analyze:server and analyze:browser to scripts
* with-webpack-bundle-analyzer example: fix typo
