`<Container>` does not receive any property. There is no way the *scrollToHash* logic can work right now. I believe it's a regression. It was working fine at some point. I'm sorry, I'm too lazy to add a test.
This fix was tested on Material-UI 👌.
This bug reproduction is the following:
As soon as you want to transition to a new page with a hash. The scroll doesn't change.
- start on pageA
- you scrollTop to 100
- you move to pageB#hash
- you stay at scrollTop 100, but #hash is at scrollTop 400.
* Throw error if getInitialProps is defined as as instance method
Omitting the static keyword happens pretty often. Therefore we should trigger a warning in devmode.
Closes: #4782
* Document getInitialProps error
* Add unit tests for loadGetInitialProps
## Issue
Running [examples/with-custom-babel-config](https://github.com/zeit/next.js/tree/canary/examples/with-custom-babel-config) will result in the following error message:
```
./pages/index.js
Module build failed (from /some_path/next.js/dist/build/webpack/loaders/next-babel-loader.js):
Error: [BABEL] /some_path/next.js/examples/with-custom-babel-config/pages/index.js:
As of v7.0.0-beta.55, we've removed Babel's Stage presets.
Please consider reading our blog post on this decision at
https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
for more details. TL;DR is that it's more beneficial in the
long run to explicitly add which proposals to use.
...
```
## Explanation
Babel removed Babel's Stage presets on July 27, 2018.
More info: https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
## Solution
I've updated the example so ist just uses the babel plugin it actually needs.
## Related
Closes: #4772
## Context
When upgrading to Next.js 6.1.1-canary.4 and using the `emit-file-loader` included in Next.js, the following error is thrown:
```bash
error in ./src/graveyard/pages/_app.scss
Module build failed (from ../node_modules/next/dist/build/webpack/loaders/emit-file-loader.js):
TypeError: Cannot read property 'context' of undefined
at Object.module.exports (~/project-root/node_modules/next/dist/build/webpack/load
ers/emit-file-loader.js:27:68)
@ ./src/pages/_app.js 35:0-53 156:17-26 157:13-22
@ multi ./pages/_app.js
```
`next.config.js` (shortened):
```js
module.exports = {
webpack: (config, { dev }) => {
config.module.rules.push({
test: /\.scss$/,
use: [
{
loader: 'emit-file-loader',
options: {
name: 'dist/[path][name].[ext].js'
}
},
{
loader: 'babel-loader',
options: {
babelrc: false,
extends: path.resolve(__dirname, './src/.babelrc')
}
},
'styled-jsx-css-loader',
{ loader: 'postcss-loader', options: { sourceMap: dev } },
{
loader: 'sass-loader',
options: {
sourceMap: dev
}
}
]
});
return config;
}
};
```
## Suggested Fix
A quick Google search brought me to a [related issue in `webpack-loader`](https://github.com/webpack-contrib/worker-loader/issues/125). As pointed out in the [Webpack docs](https://webpack.js.org/api/loaders/#this-rootcontext):
> Starting with webpack 4, the formerly `this.options.context` is provided as `this.rootContext`.
This PR makes this change while maintaining backward compatibility.
## System information
Next.js: 6.1.1-canary.4
Node: v9.3.0
Changes:
- Use css prop on the element to style it
- Add webpack + babelrc configuration to remove otherwise needed import boilerplate [according to glamor docs](https://github.com/threepointone/glamor/blob/master/docs/createElement.md)
Rationale: The killer feature of glamor that makes it so great is that it relieves you from naming classes/styles if you use the custom css prop. Together with the babel plugin you also don't need any extra import wherever the css prop is used.
All the real world uses I've seen of glamor has used the css props so I think the example should reflect this. As an example here is docs how to use glamor with gatsby (using the css prop):
https://www.gatsbyjs.org/docs/glamor/
Changes:
* moved the configuration from HOC to `_app.js`
* fixed the example, as `componentDidCatch` catches errors during rendering phase, but not within event handlers.
Depends on https://github.com/zeit/next-plugins/pull/228
Failing tests are expected as `@zeit/next-css` has to be updated/released first.
This implements rendering of `.css` chunks. Effectively removing the custom document requirement when adding next-css/sass/less/stylus.
* Compile pages to .next/static/<buildid>/pages/<page>
* Fix test
* Export class instead of using exports
* Use constant for static directory
* Add comment about what the middleware does
Changes:
* updated packages
* moved the content of `layout` to `_app.js` and created simple `Page` component
* replaced `import * as React` because it is not necessary to import everything
* moved `next.js.flow` to `flow-typed` as it is default directory for library definitions
* updated the gif
The existing example currently does not work because of outdated usage patterns. This PR seeks to update these patterns to the latest recommended best practice while bumping versions.
# Summary
- Bumped version numbers in `package.json`;
- Moved `<link />` tag from `pages/index.js` to `pages/_document.js` as is [recommended](https://github.com/zeit/next-plugins/tree/master/packages/next-css#usage);
- Replace individual css/font imports with import of minified CSS as is [recommended](https://react.semantic-ui.com/usage#semantic-ui-css-package);
- Removed prop (no longer used) from `<List />` element.
I’ve been experimenting with Next.js and Fastify and I made the following changes to the Fastify example based on what I found:
### Use Fastify’s plugin API
IMO putting Fastify’s listen call in a promise callback is an anti-pattern, b/c the Fastify plugin API is meant to solve the problem of async server bootstrapping.
[From Fastify’s Getting Started docs](https://www.fastify.io/docs/latest/Getting-Started/):
> Fastify provides a foundation that assists with the asynchronous bootstrapping of your application.
### Set reply.sent in handlers which return promises
[From Fastify’s Routes docs](https://www.fastify.io/docs/latest/Routes/#promise-resolution):
> If your handler is an `async` function or returns a promise, you should be aware of a special behaviour which is necessary to support the callback and promise control-flow. If the handler's promise is resolved with `undefined`, it will be ignored causing the request to hang and an *error* log to be emitted.
>
> 1. If you want to use `async/await` or promises but respond a value with `reply.send`:
> - **Don't** `return` any value.
> - **Don't** forget to call `reply.send`.
> 2. If you want to use `async/await` or promises:
> - **Don't** use `reply.send`.
> - **Don't** return `undefined`.
`app.render` returns a promise which contains undefined, so returning it in a Fastify handler will log an error. However, returning anything besides undefined will cause Fastify to try to write to the response which Next.js has already ended. The solution is to manually set the `reply.sent` flag to true when any Next.js rendering promise is fulfilled as an alternative to calling `reply.send`.
### Make Next.js handle 404 errors
This allows any route to throw a NotFound error and let Next.js handle the rendering of the 404 page.
### Make Next.js handle any route which starts with `_next` in dev
This prevents dev routes from being caught by user-defined routes.
