withApollo example - move from old HOC APIs to new function-as-child APIs (#5241)
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!
2018-09-25 23:32:41 +00:00
|
|
|
import { Query } from 'react-apollo'
|
2017-10-28 07:19:56 +00:00
|
|
|
import gql from 'graphql-tag'
|
2017-07-01 21:56:12 +00:00
|
|
|
import ErrorMessage from './ErrorMessage'
|
2017-01-22 12:27:06 +00:00
|
|
|
import PostUpvoter from './PostUpvoter'
|
|
|
|
|
withApollo example - move from old HOC APIs to new function-as-child APIs (#5241)
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!
2018-09-25 23:32:41 +00:00
|
|
|
export const allPostsQuery = gql`
|
2017-01-22 12:27:06 +00:00
|
|
|
query allPosts($first: Int!, $skip: Int!) {
|
|
|
|
allPosts(orderBy: createdAt_DESC, first: $first, skip: $skip) {
|
|
|
|
id
|
|
|
|
title
|
|
|
|
votes
|
|
|
|
url
|
|
|
|
createdAt
|
2017-12-05 18:50:45 +00:00
|
|
|
}
|
2017-01-22 12:27:06 +00:00
|
|
|
_allPostsMeta {
|
|
|
|
count
|
|
|
|
}
|
|
|
|
}
|
|
|
|
`
|
2017-11-16 10:18:25 +00:00
|
|
|
export const allPostsQueryVars = {
|
|
|
|
skip: 0,
|
withApollo example - move from old HOC APIs to new function-as-child APIs (#5241)
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!
2018-09-25 23:32:41 +00:00
|
|
|
first: 10
|
|
|
|
}
|
|
|
|
|
|
|
|
export default function PostList () {
|
|
|
|
return (
|
|
|
|
<Query query={allPostsQuery} variables={allPostsQueryVars}>
|
|
|
|
{({ loading, error, data: { allPosts, _allPostsMeta }, fetchMore }) => {
|
|
|
|
if (error) return <ErrorMessage message='Error loading posts.' />
|
|
|
|
if (loading) return <div>Loading</div>
|
|
|
|
|
|
|
|
const areMorePosts = allPosts.length < _allPostsMeta.count
|
|
|
|
return (
|
|
|
|
<section>
|
|
|
|
<ul>
|
|
|
|
{allPosts.map((post, index) => (
|
|
|
|
<li key={post.id}>
|
|
|
|
<div>
|
|
|
|
<span>{index + 1}. </span>
|
|
|
|
<a href={post.url}>{post.title}</a>
|
|
|
|
<PostUpvoter id={post.id} votes={post.votes} />
|
|
|
|
</div>
|
|
|
|
</li>
|
|
|
|
))}
|
|
|
|
</ul>
|
|
|
|
{areMorePosts ? (
|
|
|
|
<button onClick={() => loadMorePosts(allPosts, fetchMore)}>
|
|
|
|
{' '}
|
|
|
|
{loading ? 'Loading...' : 'Show More'}{' '}
|
|
|
|
</button>
|
|
|
|
) : (
|
|
|
|
''
|
|
|
|
)}
|
|
|
|
<style jsx>{`
|
|
|
|
section {
|
|
|
|
padding-bottom: 20px;
|
|
|
|
}
|
|
|
|
li {
|
|
|
|
display: block;
|
|
|
|
margin-bottom: 10px;
|
|
|
|
}
|
|
|
|
div {
|
|
|
|
align-items: center;
|
|
|
|
display: flex;
|
|
|
|
}
|
|
|
|
a {
|
|
|
|
font-size: 14px;
|
|
|
|
margin-right: 10px;
|
|
|
|
text-decoration: none;
|
|
|
|
padding-bottom: 0;
|
|
|
|
border: 0;
|
|
|
|
}
|
|
|
|
span {
|
|
|
|
font-size: 14px;
|
|
|
|
margin-right: 5px;
|
|
|
|
}
|
|
|
|
ul {
|
|
|
|
margin: 0;
|
|
|
|
padding: 0;
|
|
|
|
}
|
|
|
|
button:before {
|
|
|
|
align-self: center;
|
|
|
|
border-style: solid;
|
|
|
|
border-width: 6px 4px 0 4px;
|
|
|
|
border-color: #ffffff transparent transparent transparent;
|
|
|
|
content: '';
|
|
|
|
height: 0;
|
|
|
|
margin-right: 5px;
|
|
|
|
width: 0;
|
|
|
|
}
|
|
|
|
`}</style>
|
|
|
|
</section>
|
|
|
|
)
|
|
|
|
}}
|
|
|
|
</Query>
|
|
|
|
)
|
2017-11-16 10:18:25 +00:00
|
|
|
}
|
2017-01-22 12:27:06 +00:00
|
|
|
|
withApollo example - move from old HOC APIs to new function-as-child APIs (#5241)
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!
2018-09-25 23:32:41 +00:00
|
|
|
function loadMorePosts (allPosts, fetchMore) {
|
|
|
|
fetchMore({
|
|
|
|
variables: {
|
|
|
|
skip: allPosts.length
|
|
|
|
},
|
|
|
|
updateQuery: (previousResult, { fetchMoreResult }) => {
|
|
|
|
if (!fetchMoreResult) {
|
|
|
|
return previousResult
|
2018-05-07 13:02:56 +00:00
|
|
|
}
|
withApollo example - move from old HOC APIs to new function-as-child APIs (#5241)
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!
2018-09-25 23:32:41 +00:00
|
|
|
return Object.assign({}, previousResult, {
|
|
|
|
// Append the new posts results to the old one
|
|
|
|
allPosts: [...previousResult.allPosts, ...fetchMoreResult.allPosts]
|
|
|
|
})
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|