Conditionally Append Headers for useQuery Call

[sammous1]

I think this is more of a question/feature-request, but based on looking at docs and source code, I believe that if you pass any headers to a useQuery call via context.fetchOptions.headers, that those will be the ones used for the query rather than a union of those passed and those defined on the client - is that correct? Is there any way to conditionally pass an additional header on a query-by-query basis such that all headers defined at the client level are used in additional to the new header?

urql version & exchanges:

"urql": "^2.2.0",
"@urql/devtools": "^2.0.0",
"@urql/exchange-persisted-fetch": "^1.3.4",

Steps to reproduce

1. Define headers when creating urql client
2. Call useQuery with an additional header defined in context.fetchOptions.headers

Expected behavior Be able to append a header to a query rather than re-define all headers

Actual behavior Header specified in context.fetchOptions.headers overwrites the headers defined at the client-level

[JoviDeCroock]

Hmm, currently we are not merging the default and extra options, which is located here this could be because when we think about selective overrides. i.e. we override the url it could need other headers so overriding could prove troublesome. I'm not sure whether it's worth that 😅 We also can't just remove one header etc so I think it's easier to start with a clean slate

[kitten]

Header specified in context.fetchOptions.headers overwrites the headers defined at the client-level

Sorry, can you clarify what you're after? There's only one header that's added by default. If you mean specifying headers in the UI bindings: we do allow passing context option overrides in all bindings for completeness but it's not meant to be used for UI logic. Meaning, if you permanently define headers there it may be more convenient to write an exchange to do this based on the operation for you

[kitten]

Closing due to inactivity. I'm still happy to come back to this and discuss what the underlying motivation is, which may mean we'll be able to reopen this :v: