* 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
Since version 2.1, react-apollo is exposing some new components that use the function-as-child (or render-prop) pattern to let you connect apollo-client magic with your components. See the blog article: [New in React Apollo 2.1](https://www.apollographql.com/docs/react/react-apollo-migration.html)
If I'm not mistaken, it's generally agreed that this pattern is (where it works) superior to the HOC pattern, for reasons that are best explained here: https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce
So I updated the with-apollo example to use the new API, and IMO this code is much simpler and natural to read and understand, especially if you are not already familiar with Apollo's HOC APIs.
I broke up my changes into separate commits, for easier review. Commits with "Refactor" in the message accomplish the goal of switching to the new APIs while minimizing line-by-line differences (select "Hide whitespace changes" under "Diff settings"). Commits with "Clean up" in the message follow up the refactoring with trivial things like reorganizing code sections, renaming variables, etc.
For the components doing mutations, I chose not to use the `Mutation` component, since that doesn't really make sense to me; a mutation is something that happens at a point in time, so it's not meaningful to represent a mutation in the markup, which exists for a period of time. All that component does is expose a `mutate` function for a single specified mutation, and `result` data for a single firing of the mutation (which we don't need anyways; apollo handles updating the local data with the result). To me it seems simpler and more flexible to just get the apollo client via `ApolloConsumer` and call `.mutate()` on it.
In case anyone is interested, here's what my version of `PostUpvoter` using the `Mutation` component looked like:
<details>
```jsx
import React from 'react'
import { Mutation } from 'react-apollo'
import { gql } from 'apollo-boost'
export default function PostUpvoter ({ votes, id }) {
return (
<Mutation mutation={upvotePost}>
{mutate => (
<button onClick={() => upvote(id, votes + 1, mutate)}>
{votes}
<style jsx>{`
button {
background-color: transparent;
border: 1px solid #e4e4e4;
color: #000;
}
button:active {
background-color: transparent;
}
button:before {
align-self: center;
border-color: transparent transparent #000000 transparent;
border-style: solid;
border-width: 0 4px 6px 4px;
content: '';
height: 0;
margin-right: 5px;
width: 0;
}
`}</style>
</button>
)}
</Mutation>
)
}
const upvotePost = gql`
mutation updatePost($id: ID!, $votes: Int) {
updatePost(id: $id, votes: $votes) {
id
__typename
votes
}
}
`
function upvote (id, votes, mutate) {
mutate({
variables: { id, votes },
optimisticResponse: {
__typename: 'Mutation',
updatePost: {
__typename: 'Post',
id,
votes
}
}
})
}
```
</details>
###
I'm happy with where things are at here, but I'm more than happy to address any comments, concerns, ideas for improvent!
Thanks!
This fixes https://github.com/zeit/next.js/issues/5260 by making sure that `index.js` has `getInitialProps` defined on the page exported component, not the child component.
When fixing that, I uncovered an issue where the server side rendered HTML did not match the clientside HTML, so I reworked _app.js to use the `i18nextprovider` component which has props to hydrate the initial data (for SSR), and makes sure the correct i18n instance is passed to all child components through context.
Before:
```html
<!DOCTYPE html>
<html>
<head>
<meta charSet="utf-8" class="next-head"/>
<link rel="preload" href="/_next/static/development/pages/index.js" as="script"/>
<link rel="preload" href="/_next/static/development/pages/_app.js" as="script"/>
<link rel="preload" href="/_next/static/development/pages/_error.js" as="script"/>
<link rel="preload" href="/_next/static/runtime/webpack.js" as="script"/>
<link rel="preload" href="/_next/static/runtime/main.js" as="script"/>
</head>
<body>
<div id="__next"></div>
<script src="/_next/static/development/dll/dll_4a2ab6ce0cb456fbfead.js"></script><script>__NEXT_DATA__ = {"props":{"pageProps":{}},"page":"/","pathname":"/","query":{},"buildId":"development"};__NEXT_LOADED_PAGES__=[];__NEXT_REGISTER_PAGE=function(r,f){__NEXT_LOADED_PAGES__.push([r, f])}</script><script async="" id="__NEXT_PAGE__/" src="/_next/static/development/pages/index.js"></script><script async="" id="__NEXT_PAGE__/_app" src="/_next/static/development/pages/_app.js"></script><script async="" id="__NEXT_PAGE__/_error" src="/_next/static/development/pages/_error.js"></script><script src="/_next/static/runtime/webpack.js" async=""></script><script src="/_next/static/runtime/main.js" async=""></script>
</body>
</html>
```
After:
```html
<!DOCTYPE html>
<html>
<head>
<meta charSet="utf-8" class="next-head"/>
<link rel="preload" href="/_next/static/development/pages/index.js" as="script"/>
<link rel="preload" href="/_next/static/development/pages/_app.js" as="script"/>
<link rel="preload" href="/_next/static/development/pages/_error.js" as="script"/>
<link rel="preload" href="/_next/static/runtime/webpack.js" as="script"/>
<link rel="preload" href="/_next/static/runtime/main.js" as="script"/>
</head>
<body>
<div id="__next">
<h1>This example integrates react-i18next for simple internationalization.</h1>
<div>
<h1>welcome to next.js</h1>
<p>This example integrates react-i18next for simple internationalization.</p>
<p>test words for en</p>
<div><button>fire in the wind for en</button></div>
<p>You can either pass t function to child components.</p>
<p>Or wrap your component using the translate hoc provided by react-i18next.</p>
<p>Alternatively, you can use <code>Trans</code> component.</p>
<a href="/page2">Go to page 2</a><br/><a href="/page3">Go to page 3 (no hoc)</a>
</div>
</div>
<script src="/_next/static/development/dll/dll_4a2ab6ce0cb456fbfead.js"></script><script>__NEXT_DATA__ = {"props":{"pageProps":{"i18n":null,"initialI18nStore":{"en":{"home":{"welcome":"welcome to next.js","sample_test":"test words for en","sample_button":"fire in the wind for en","link":{"gotoPage2":"Go to page 2","gotoPage3":"Go to page 3 (no hoc)"}},"common":{"integrates_react-i18next":"This example integrates react-i18next for simple internationalization.","pureComponent":"You can either pass t function to child components.","extendedComponent":"Or wrap your component using the translate hoc provided by react-i18next.","transComponent":"Alternatively, you can use \u003c1\u003eTrans\u003c/1\u003e component."}}},"initialLanguage":"en-US"}},"page":"/","pathname":"/","query":{},"buildId":"development"};__NEXT_LOADED_PAGES__=[];__NEXT_REGISTER_PAGE=function(r,f){__NEXT_LOADED_PAGES__.push([r, f])}</script><script async="" id="__NEXT_PAGE__/" src="/_next/static/development/pages/index.js"></script><script async="" id="__NEXT_PAGE__/_app" src="/_next/static/development/pages/_app.js"></script><script async="" id="__NEXT_PAGE__/_error" src="/_next/static/development/pages/_error.js"></script><script src="/_next/static/runtime/webpack.js" async=""></script><script src="/_next/static/runtime/main.js" async=""></script>
</body>
</html>
```
* Update .babelrc
babel-plugin-transform-decorators-legacy does not exist in babel 7 in replace use @babel/plugin-proposal-decorators
* Update package.json
Acording the last commit please, test this example , will be work .
Though it sounds like some folks do run getDataFromTree() on the client in order to avoid loading states, it's non-standard usage and potentially confusing. Also it's inconsistent with the other with-apollo examples.
The `with-flow` sample has some obsolete definitions which are unused by the sample code. Removing the un-imported declarations is the easiest approach.
Hi
In the current version of the example __custom-server-typescript__, types are never checked.
For instance, change the following line :
```
const dev = process.env.NODE_ENV !== 'production'
```
by :
```
const dev: number = process.env.NODE_ENV !== 'production'
```
then run `npm run dev`. The application launches perfectly, no error is thrown.
In dev environnement, it is preferable to check types all the time, to get immediate feedback. This PR activates type checking. Only when using nodemon, so no impact on production.
Now the above code will (rightfully) refuse to compile :
```
TSError: ⨯ Unable to compile TypeScript
server/index.ts (6,7): Type 'boolean' is not assignable to type 'number'
```
I simplified the example by removing `.eslintrc.js` and related packages, as well as `nodemon`.
I also added a description in the README to address the question by @kachkaev in the original pull request (#4163).
I think I accidentally deleted the branch my prior PR was based on before you had a chance to merge or decide whether to merge. In case I borked things with that delete, I'm resubmitting the PR and figuring you can close one or the other or both as desired.
Original notes:
Based on with-mobx-state-tree, but typescript instead of javascript
Aside from a few bits of typing and renaming .js files to .ts and .tsx, most of the the edits are to avoid warnings and errors when running the code through tslint (which can be done via the `npm run tslint` command in the example if desired).
To keep this example simple, the `<styled>` component (which is used by the javascript-based with-redux and with-mobx-state-tree examples for the clock component) is not used in this example. The `<styled>` library can of course be used with typescript but (I think) it requires a more complicated set of typescript and babel .configs than is needed for most other components and libraries, so I'm just directly styling the one formerly `<styled>` div to keep things simple and broadly applicable.
> Workspaces are a new way to setup your package architecture that’s available by default starting from Yarn 1.0. It allows you to setup multiple packages in such a way that you only need to run yarn install once to install all of them in a single pass.
- [x] Tested in development mode
- [x] Tested in production mode
- [x] Tested with deployment https://with-yarn-workspaces-hwzubdlkul.now.sh/
- [x] Added transpile module example
Closes#3638
Pulling out a few core points from the readme...
This example builds from /src into /dist, managing the different expectations of express.js (es5, commonjs) and next.js (es6) by using a pair of tsconfig.json files, both of which are run by `npm run build-ts` or any of the other npm targets.
Hot module reloading is largely but not completely wired up (nodemon is watching /dist but tsc isn't set up to watch /src and transpile changes in /src to /dist automatically (that's mainly because I wasn't sure how to start both nodemon and a pair of tsc watchers and be confident all would get shut down when the user killed dev mode). The readme suggests running `npm run build-ts` manually in another window to push changes from /src into /dev and on into the browser.
tslint is also wired up via `npm run tslint`
The original example fails to compile on my windows machine but updating bs-platform fixes that.
Depending on bs-next causes example to fail (package compiled with old incompatible version of bs-platform) so I have included it in a bindings directory where it can serve as an example of reason bindings.
Sources have been migrated to the latest reason-react.
Running the [with-jest](https://github.com/zeit/next.js/tree/canary/examples/with-jest) example results in the following error:
```log
FAIL __tests__/index.test.js
● Test suite failed to run
SecurityError: localStorage is not available for opaque origins
at Window.get localStorage [as localStorage] (node_modules/jsdom/lib/jsdom/browser/Window.js:257:15)
at Array.forEach (<anonymous>)
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time: 0.943s
Ran all test suites.
error Command failed with exit code 1.
```
Upgrading the dependencies (jest) to the latest version helps!
[More info](https://github.com/jsdom/jsdom/issues/2304)
Related #4776
* replace componentWillReceiveProps by componentDidUpdate
* replace props.url by withRouter HOC
* fix deprecated `props.url` in with-shallow-routing example
Fixes#4691Fixes#4614
This PR gives path to https://github.com/zeit/next-plugins/pull/242
I did not add or remove `^` near dependency versions in package.json files. However, I don't exclude that some changes can be made given that rc is more stable than beta.
Changes:
* Split `Header` component trough `_document.js` and `_app.js`
* Attached Router events with a way described in the [documentation](https://github.com/zeit/next.js#router-events) (though in the documentation is says it should be `Router.events.on` while I managed to get it working only by `Router.router.events.on` and I had to place it inside `componentDidMount`)
## 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
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.
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.
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 🎉
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>
```
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.
