React-apollo: Query delay and Render prop load

[scragz]

https://www.apollographql.com/docs/react/essentials/queries.html#api

<Query>
delay: boolean
If delay is true, the Query component will not fetch the query on mount although its children will still render. Use delay with load in the render prop function to manually fire the query.

Render prop
load: () => void
A function to manually fetch the query instead of fetching when the component mounts. Use with the delay prop on the Query component. Useful for prefetching data

So something like this should work:

<Query query="something" delay="true>
{({ loading, error, data, load }) => {
return <button onClick={load}>
}}
</Query>

Intended outcome:

Runs the query on click.

Actual outcome:

load is undefined.

How to reproduce the issue:

see above

Version

• [email protected]
• [email protected]

I'm new to the project so I'm not totally sure if this is the documentation being ahead of the source code or the documentation still reflecting an API that changed.

[artola]

could be?
delay= skip
load = refetch

[theodorDiaconu]

here is called delay
https://www.apollographql.com/docs/react/essentials/queries.html#props
and load() is present

here is called skip:
https://www.apollographql.com/docs/react/api/react-apollo.html#query
refetch() is present

[rivertam]

This is a weird oversight in the docs. delay doesn't seem to do anything for me (query fetches on mount). When I specify skip, it does not fetch, but refetch doesn't make it fetch either (though it is present). loading is true throughout.

[MaanuVazquez]

Same for me, delay does nothing, the query is sent when render is called

[sirganya]

I notice in the docs it uses a consumer component instead of "delay" to achieve this.
https://www.apollographql.com/docs/react/essentials/queries.html#manual-query

[damien-monni]

Same for me. Delay doesn't seem to do anything.
I see in the docs we need to use a consumer, but it would be much better if we could use this delay prop with the load function.

[ghost]

Here is my workaround for this.
https://gist.github.com/iykyvic/77872ce93963c66af86331143e2de656

[coodoo]

Just tried this with apollo-boost v1.6.0, can confirm that delay on <Query> did work, but there's no load passed into render props fn, probably a bug?

[coodoo]

Bump!

I did a quick search in the code base and can't seemed to find any places that mentioned delay and load, wondering is this feature implemented in other branches?

Would appreciate anyone one the team to chime in, thanks!

[salesfelipe]

I've also tried to use the delay option to not call the query on mount, but had no success either. So the only option I've could find so far was using ApolloConsumer. In my case, I had to call a query and a mutation right after. I will leave my commit here for future reference, for those who need to do something similar.

https://github.com/vtex-apps/storecomponents/pull/53/commits/b2d13b9520a31d30dbb67311b791265c69b6e2a5

[tylerjbainbridge]

Bump-- definitely weird that this is included in the docs, but not present in the code base.

Would appreciate some help here :)

[lostpebble]

Yes, could we please get some clarity on this. The current recommended way of using ApolloConsumer manually seems like a bit of a work around and this kind of functionality should be built into the Query component.

The use case of a delayed query is very common. e.g. updating an input and then clicking a button to pass that value to a query.

[jimmybrawn]

Bump it up!

[mu1ex]

Yup, not sure why its in docs, temporarily Ive created a delayed query component based on the apollo consumer method for firing queries manually. Ive shared the gist below.

https://gist.github.com/mu1ex/c084dbf7b94db1c06d031d87f9e0f5d7

[ghost]

The graphql HOC wrapper can be used to do this easily.

import { graphql } from 'react-apollo'

graphql(YOUR_QUERY_MUTATION_FRAGMENT, {
    props: ({
      data: {
        yourData,
        error,
        loading,
        fetchMore,
        refetch
      }
    }) => ({ loading, error, fetchMore, refetch, yourData }),
    options: {
      variables: { /* your variables */ }
    },
    skip: props => props.yourProp === 'your condition'
  })(YourComponent)

[kirill-konshin]

Bump!

[rafrsr]

I have a headache, after reading the doc and try and try again, and again this new feature, I tried with all versions(latest,alpha, next ...), but nothing... this feature is not available yet or is a proposal? why the documentation explain a feature not available in any version?

[sgtpepper43]

Okay how the heck has this issue been up for months with no clear answer? Has no maintainer even looked at this issue?
It was added to the docs here
Hey @peggyrayzis, why did you add load to the docs?

[isopterix]

I was just hunting this down and ended up here as well ;( Please, let us know what the status on this one is.

[verzil]

i did a search inside of the repo, the only delay it accept is a type of number, and it is used in conjunction with a test. I don't really know if the feature is implemented or its still in the planning phase.
Also skip does nothing for me as well.

[hwillson]

Ouch - sorry all! I'll dig into this and have an answer shortly. I haven't worked through the React Apollo issue backlog yet, and didn't see this until I hit https://github.com/apollographql/apollo-client/pull/3806 for review 🙁. My guess is that we're removing them from the docs for now, but I'll get the backstory and post back. Thanks!

[hwillson]

Okay, got the backstory. delay and load should not be in the docs. They were ideas that were part of an API sketch a while back, that were potentials to be implemented. They didn't make the cut though and the docs were accidentally published ☹️. I'm sorry for the confusion this has caused! In the future, if anyone notices issues like this that aren't getting the attention they deserve, please by all means @ mention me directly.

[coodoo]

@hwillson thanks for the update, and since we are at it what's your take on actually having those implemented for that there seems to be rather strong needs for them? :)

[hwillson]

@coodoo I like the idea! I closed this issue a bit prematurely, since we should keep it open as a feature request. We've moved to using a new feature request specific repo for Apollo Client, and at some point soon we're going to do the same for this repo (all feature requests will be managed under http://github.com/apollographql/apollo-feature-requests). Since we're not quite ready to house React Apollo FR's in that repo though, I'll re-open this for now. Thanks!

[kamaltmo]

Thanks for looking into this and feeding back how this happened @hwillson, much appreciated

[isopterix]

Too bad that this FR was dropped for the moment. I am just facing a similar need and the option to purposely trigger the query without the need to go through a Consumer component would be so much cleaner...

[good-idea]

My temporary solution was to create an 'enhanced' <Query> component that re-introduces this functionality. I'm using delayQuery and loadQuery instead of delay and load to avoid any compatibility problems.

My use case was exactly what @lostpebble mentioned:

The use case of a delayed query is very common. e.g. updating an input and then clicking a button to pass that value to a query.

This does the trick, but with the drawback that when you use loadQuery, you don't get updated render props, such as networkStatus, which could be helpful. But, loadQuery will return a full Apollo response.

This isn't battle-tested and might need some tweaks, use with caution!

Here is the gist

The code from the gist at the time of posting:

// @flow
import * as React from 'react'
import type { DocumentNode } from 'graphql'
import type { QueryRenderProps } from 'react-apollo'
import { Query as ApolloQuery } from 'react-apollo'

type QueryProps = {
    query: DocumentNode,
    children: (QueryRenderProps<any, any>) => React.Node,
    variables?: {},
    delayQuery?: boolean,
    skip?: boolean,
    displayName?: void | string,
    notifyOnNetworkStatusChange?: boolean,
    ssr?: boolean,
    pollInterval?: number,
    // Incomplete, missing:
    // fetchPolicy?: FetchPolicy
    // errorPolicy?: ErrorPolicy
}

const Query = ({ children, skip, delayQuery, ...queryProps }: QueryProps) => (
    <ApolloQuery {...queryProps} skip={skip || delayQuery}>
        {(response) => {
            const { client } = response
            // if `delay === true`, supply in a 'load' function to manually fire the query
            // and return the results
            const loadQuery = async (variables) =>
                client.query({
                    query: queryProps.query,
                    variables,
                })

            const renderProps = delayQuery
                ? {
                        loadQuery,
                        ...response,
                  }
                : response

            return children(renderProps)
        }}
    </ApolloQuery>
)

Query.defaultProps = {
    variables: {},
    displayName: undefined,
    skip: false,
    delayQuery: false,
    notifyOnNetworkStatusChange: true,
    ssr: false,
    pollInterval: 0,
}

export default Query

[alamothe]

It should be possible to use Query with fetchPolicy="cache-only" (this way it won't make a network request by itself ever), together with refetch later to get the intended behavior.

EDIT: Actually this will produce the error:

Error: cache-only fetchPolicy option should not be used together with query refetch.

Not sure if it's purely an artificial check on part of Apollo?

It does work with fetchMore, however that's more hassle because query, variables, and updateQuery have to be specified. Another solution is to use client directly like some of the answers are doing.

[hwillson]

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, React Apollo feature requests are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the outstanding feature requests are still considered to be of value to the community. Thanks!