Allow options to be passed to TypePolicy from useQuery

[mschipperheyn]

We have implemented (the new) pagination TypePolicies. By elevating the merge action to a higher level of abstraction we have run into a limitation. Our queries allow you to choose between cursor based and page based pagination. This still works.

But we also allow you to select whether you want to concat the result or replace. Concat is commonly used with infinite lists and replace is used with traditional list style pagination.

Since we use the same queries to generate data for either style, e.g.

	fragment basePageInfoFragment on PageInfo {
		... on Page {
			hasNextPage
			hasPreviousPage
			pageSize
		}
		... on PageInfoInt {
			page
		}
	}

	fragment pageInfoFragment on PageInfo {
		...basePageInfoFragment
		... on PageInfoCursor {
			startCursor
			endCursor
		}
	}


	query Social__Groups(
		$page: Int = 0
		$pageSize: Int = 10
		$filter: String
		$sort: String
		$after: String
		$before: String
		$isCursor: Boolean = true
	) {
		social__groups(
			pageSize: $pageSize
			isCursor: $isCursor
			filter: $filter
			sort: $sort
			after: $after
			before: $before
			page: $page
		) {
			edges {
				node {
					...listGroupFragment
					createdAt
					updatedAt
				}
				cursor
			}
			pageInfo {
				...pageInfoFragment
			}
			totalCount
		}
	}

Since we can define only 1 pagination field type for a query, we have made a switching paginator that switches to the cursor or page based pagination based on the pageInfo __typename parameter. However, there doesn't seem to be any way to tell the merge function to use infinite or replace style pagination on the fly. The "hard coded" options you can pass while instantiating the field policy don't give you per useQuery or per fetchMore flexibility.

A workaround would be to define an extra variable in the query definition, but it would be sent to the server and it just seems inelegant to involve the server in a purely client side choice.

I would like to be able to send additional options fetchMore({ variables: { page: 1 }, opts: { inifinite: true } }) or useQuery({ variables: { page: 0 }, opts: { inifinite: true } })

Feature requests should include as much detail as possible:

• [x ] A descriptive title
• [ x] A description of the problem you're trying to solve, including why you think this is a problem
• [x ] An overview of the suggested solution
• [ x] If the feature changes current behavior, reasons why your solution is better