Add networkStatus prop to connected components

[cannoneyed]

Steps to Reproduce

When fetching more data, using a pattern identical to that proposed in the docs, the loading prop that is passed down to the wrapped component is false after fetchMore is invoked.

const Query = gql`
query paginatedQuery ($offset: Int) {
    paginatedItems (offset: $offset) {
        ... item
    }
}
`
@graphql(Query, {
    props:  ({ data }) => {
        const { fetchMore } = data
        const queryResult = data.paginatedItems

        data.loadNextPage = () => fetchMore({
            variables: {
                offset: queryResult.length
            },
            updateQuery: (prev, { fetchMoreResult }) => {
                if (!fetchMoreResult.data) {
                    return prev
                }

                return Object.assign({}, prev, {
                    [queryName]: [
                        ...prev[queryName],
                        ...fetchMoreResult.data.paginatedItems
                    ]
                })
            }
        })

        return { data }
    }
}
class View extends Component {
    render() {
        const { data: { paginatedItems, loading, loadNextPage } } = this.props
        // Loading is false after loadNextPage is invoked
    }
}

Buggy Behavior

It seems the loading prop is only ever tied to the initial load of data. For simple components that don't need to update or paginate, this is fine. However, the workaround for this (managing refetch / loadMore status with local component state) is not ideal.

Expected Behavior

The following PR apollographql/apollo-client#707 in apollo client exposes a networkStatus object for handling the status of non-initial-load network requests, such as refetch, fetchMore, and subscriptions.

It would be very nice to have the networkStatus object exposed as a prop to wrapped components (perhaps if specified as an option), so that paginated / more complex query operations loading/error state can be managed by the react-apollo wrapper rather than using local ad-hoc local component state.

Version

• [email protected]
• [email protected]

[helfer]

@cannoneyed FYI, the fetchingMore network status isn't implemented in apollo-client yet. All others should be.

[vovacodes]

I would like to implement this functionality since my app depends on it. @jbaxleyiii @cannoneyed @helfer Is anybody working on it now?

[cannoneyed]

@wizardzloy I'm starting to look into this now.

[cannoneyed]

@helfer @wizardzloy So what I've found so far is that there seems to be some work needed in apollo-client... it looks like when ObservableQuery.fetchMore is called, a new query is created but no corresponding listener is tied to it. All of the networkStatus stuff is being handled correctly, it's just that it's all happening on a separate query, and the only time where the connected component updates is when the original query has its data merged with the new one (in updateQuery).

This is an interesting situation. On the one hand, it totally makes sense that a fetchMore would create a new query, since it is in fact a separate, different query, with different variables and different statuses (the original one has loaded, and the new one is loading). However, it's kind of a bummer that the connected component doesn't currently have any way of knowing what the status of the "sibling" fetchMore query is. Perhaps the best way to handle this would be to expose some sort of prop that has some notion of these "sibling" queries. I'm not exactly sure what that might look like yet, but it seems like this would be very useful for more effectively managing components with multiple queries (ie paginated components)

[nicolo-paganin]

+1 this feature will be very useful

[helfer]

@cannoneyed I think we can implement this kind of tracking internally in Apollo Client and expose it just through a fetchingMore network status. Would that be enough information for your use-case?

[czert]

@helfer It would be for mine :)

[czert]

We've had the data.networkStatus prop for a while, and until 1.0.0 it worked beautifully. While "fetching more", its value was 3. In 1.0.0, though, its value doesn't change back from 7.

Is this a known effect of some other change that I missed, or should I open an issue for this?

[helfer]

@czert are you using the query option notifyOnNetworkStatusChange? If not, the component wouldn't be notified of changes in network status unless the data has also changed. If you are using that option but still aren't seeing the network status update, then it's a bug and a repro would be much appreciated! 🙂

[czert]

@helfer thanks, I wasn't using the new notifyOnNetworkStatusChange until a different issue brought it to my attention. All works fine now, thanks! :)

[jbaxleyiii]

networkStatus is included in props now