- 31 7月, 2018 1 次提交
-
-
由 Tim Neutkens 提交于
-
- 30 7月, 2018 1 次提交
-
-
由 Tim Neutkens 提交于
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.
-
- 28 7月, 2018 4 次提交
-
-
由 José Manuel Aguirre 提交于
Missing configuration in package.json and .babelrc causes this example to be broken after installing and running the example.
-
由 Tomek 提交于
-
由 Tim Neutkens 提交于
-
由 Tim Neutkens 提交于
-
- 26 7月, 2018 3 次提交
-
-
由 Stefan Ivic 提交于
Tackles the issue in #4025.
-
由 Tim Neutkens 提交于
Fixes #3775
-
由 Tomek 提交于
Changes: * replaced the `markdown-in-js` with nextjs plugin for `MDX` Highly inspired by the example from [MDX repository](https://github.com/mdx-js/mdx/tree/master/examples/next)
-
- 25 7月, 2018 3 次提交
-
-
由 Tim Neutkens 提交于
* 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
-
由 Tomek 提交于
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
-
由 Tomek 提交于
Changes: - use `next-images` plugin for handling static files import
-
- 24 7月, 2018 3 次提交
-
-
由 S. Suzuki 提交于
I found mistake on readme
-
由 Tim Neutkens 提交于
Webpack 4, react-error-overlay, react-loadable (major)
-
由 Rustam Gilyaziev 提交于
Changes: - added withIntl HOC because injectIntl do no hoist static methods - fixed `Cannot read property 'locale' of undefined`
-
- 23 7月, 2018 1 次提交
-
-
由 Tomek 提交于
Changes: * use `dynamic` imports instead of `require` * update `recharts` dependency
-
- 22 7月, 2018 3 次提交
- 21 7月, 2018 1 次提交
-
-
由 Adrian Li 提交于
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.
-
- 20 7月, 2018 1 次提交
-
-
由 Brian Kim 提交于
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.
-
- 19 7月, 2018 3 次提交
-
-
由 Tim Neutkens 提交于
-
由 Tim Neutkens 提交于
-
由 Tim Neutkens 提交于
-
- 17 7月, 2018 1 次提交
-
-
由 Lukasz Ostrowski 提交于
Fixes [this issue](https://github.com/zeit/next.js/issues/4747) I don't know what is the reason why the process does not finish, because it can be reproduced in this repo in many environments (my local mac os and Netlify pipeline). However, it fixes the problem and it's 100% safe.
-
- 16 7月, 2018 1 次提交
-
-
由 David Calhoun 提交于
-
- 14 7月, 2018 2 次提交
-
-
由 Leo Lamprecht 提交于
As per [this post](https://blog.npmjs.org/post/175824896885/incident-report-npm-inc-operations-incident-of). **This needs to be cherry-picked to master as well.**
-
由 Tim Neutkens 提交于
-
- 13 7月, 2018 2 次提交
-
-
由 Albin Ekblom 提交于
* Add support for custom App and Component enhancers * Add ctx.renderPage test * Add tests for single enhancer function * Cleanup renderPage options check * Cleanup * Add comment about backwards compatibility for renderPage * Add more test cases
-
由 Kenneth Luján Rosas 提交于
As seen on `with-apollo-auth` there are some things that need to be addressed here too. * #4554 remove useless `apolloState` from App props on `getDataFromTree` * #4563 simplify `apolloState` prop Let me know if further changes/fixes are needed. Thank you
🎉
-
- 12 7月, 2018 3 次提交
-
-
由 James Reggio 提交于
There are occasions where it is useful to have `target='_blank'` on hyperlinks within your own app. (For example, if your app is being loaded in an iframe and you'd like for the links to break out in to new windows.) With this PR, the `onClick` logic in Link now checks for an external target on the nested <a/> tag, and will fall back to the default behavior if it's present, similar to the logic for shift-/cmd-clicking the link.
-
由 James Reggio 提交于
## What's wrong This problem is specific to errors that happen on the client _after_ the initial mounting of the component. (The router has special logic to handle exceptions thrown in `getInitialProps` during a client-side navigation, and I've confirmed this logic is correct.) Specifically, if the page is mounted, and you raise an exception on the page, the exception will cause the error page to be mounted without ever invoking `getInitialProps` on the new App/Error page pairing. This has been illustrated with multiple repros in #4574. ## Why is it broken This regression was introduced two months ago in #4156, where the invocation of `getInitialProps` was removed from the app's top-level error handler. Specifically, [this line](https://github.com/zeit/next.js/pull/4156/files#diff-895656aeaccff5d7c0f56a113ede9662L147) was removed and [replaced by a comment](https://github.com/zeit/next.js/pull/4156/files#diff-895656aeaccff5d7c0f56a113ede9662R167) that says that "`App` will handle the calling of `getInitialProps`". I believe the sentiment about "`App` will handle calling `getInitialProps`" is mistaken. In fact, it really doesn't make sense on its face, since it would require an instance lifecycle method of `App` (which is mounted immediately after the comment) to invoke the `static getInitialProps` method on the error page. ## How I fixed it I've fixed this in a fork by restoring Lines 146 – 148 that were removed in #4156. I think this is the right fix, but Next.js's handling of `getInitialProps` could certainly be improved. (The code in [this conditional](https://github.com/zeit/next.js/blob/86d01706a67cee5c80796974d04c1e11cdff453a/client/index.js#L173) speaks to the unnecessary complexity around this.)
-
由 Michael Herold 提交于
Preferably this installation wouldn't be necessary, but in lieu of a fix... #4751
-
- 11 7月, 2018 2 次提交
-
-
由 Albin Ekblom 提交于
-
由 Jacob Page 提交于
* Remove nesting of runtime configuration under the babel section, since it's not related to babel. * Clean up confusing verbiage relating to "keys."
-
- 09 7月, 2018 1 次提交
-
-
由 jhartley218 提交于
Updating to a more recent version of `@types/next` fixes an error I encountered while building a new app on top of the "with-typescript" example: `Property `push` not found in SingletonRouter` Additional context: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/26665 To test, add a simple Router.push operation to the `pages/index.tsx` ``` import Router from 'next/router' // ... <span onClick={() => Router.push({ pathname: '/about' })}>TEST</span> ```
-
- 07 7月, 2018 2 次提交
-
-
由 Tim Neutkens 提交于
-
由 Tim Neutkens 提交于
-
- 06 7月, 2018 2 次提交
-
-
由 Brendan Houle 提交于
-
由 NikitaVlaznev 提交于
Apollo's getDataFromTree is supposed to be called during the server side rendering. Being called in browser it fires an unnecessary fake render process and blocks components from rendering with loading=true. Also there was a mistake in this code: // `getDataFromTree` renders the component first, the client is passed off as a property. // After that rendering is done using Next's normal rendering pipeline this.apolloClient = props.apolloClient || initApollo(props.apolloState.data) **Apollo** component is not rendered by getDataFromTree actually, it renders the **App** directly, thus props.apolloClient will always be undefined. This example was discussed here: https://github.com/zeit/next.js/issues/387.
-