0
votes

We started using the [email protected] in one of our react-redux application and we are trying to replace most of the redux stuff with graphql. So we started using the <Query> component and converted some pages to use the <Query> component. But in some pages, we have some existing logic which uses react lifecycle events like componentWillReceiveProps and if we used the <Query> component then those events won't get fired and if we use HOC type querying like below then the lifecycle events get fired and we will get the data in the props

export default graphql(GET_APP_INFO, { options: ownProps => ({ variables: { appName: ownProps.params.app } }) })

My understanding is that the component is the latest way to query and HOC is the old way which may get deprecated, also I saw some other way to query with withApollo() like below.

this.props.client.query({ query: gql..., variables: { ... }, });

So I am looking for suggestions on when to use these different types of querying patterns to get the data

2

2 Answers

1
votes

The Query component and the graphql HOC have the same basic functionality, so there shouldn't be a distinction from that perspective. Your example of the Query component not running lifecycle methods, you could move the Query component up one level out of the component, and it would work exactly the same. So something like this:

const CompQueryWrapper = () => {
  return (
    <Query ...>
      {({ data, loading, error }) => <CompWithLifecycle data={data} />}
    </Query>
}

You also might be able to move the lifecycle logic down a level. reactions/component can sometimes be handy in this case, when you just want something to trigger on a props change but don't want to go through the ceremony of making a new class component.

So yeah, for your specific situation, my recommendation would be to move the Query up so that it triggers the lifecycle or move the lifecycle logic down so it can be triggered by the Query result.

In general, the two components that I use for making queries are

  1. Query Component
  2. ApolloConsumer (it's basically just a render-prop version of withApollo)

If I can use the Query component, I use the Query component. It works for most situations. The use-case for ApolloConsumer for querying is when you don't want to immediately trigger a query. For example, say you have a form that requires some info from the user and then gets some data based on that input. It's not a mutation, since we're not changing any data, but we don't want it to fire immediately either like the Query component does. In this case, use ApolloConsumer to get the client instance, and fire the query using client.query.

1
votes

if you want use React-Apollo and run Query Dynamic , for example inside ReactLifeCycleMethod or in any other method ( for some case , when any Event listener trigger ) , you cane use Client for access Query or Mutation

React-Apollo have Consumer , with React Context API

in Top Level of your Application you implement ApolloProvider like this

 <ApolloProvider client={client} >
    < App />
 </ApolloProvider>

and now you have access client

you can create Query with Client

  client.query()

or

  client.mutate()

and if you want use client in other component you must use ( like react new Context API)

  class App extends React.Component {
     render()  {
        return(
           <ApolloConsumer >
              { client => { 

                <MyComponent accessClient={client} />

              } }
           <ApolloConsumer>  
          )
       }      
  }

now in you can access client as props

         class App extends React.Component {

            componentDidMount() {

                  this.props.accessClient.query( ... )
              }


     render()  {
        return( 
          ....
          )

       }}

https://www.apollographql.com/docs/react/essentials/queries.html#manual-query