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.
