Operation.operationName property has been depreciated with async headers

[jdgamble555]

I am using the fetchOptionsExhange to support async headers:

https://formidable.com/open-source/urql/docs/common-questions/#how-do-we-achieve-asynchronous-fetchoptions

However, I get the Operation.operationName property has been depreciated warning while debugging... rather annoying. The other proposed solution uses localStorage and authState which are NOT the same thing, and the latter being React only.

Two notes here:

1.) Could we not make this native so it works without adding this crazy code.... simply like with websockets or apollo?

• (I bet 100s of people have googled this, to have to hack it with an exchange that produces a warning...)

2.) Is it possible to get rid of the warning?

[kitten]

I'm wondering whether this is more of a question?

So first of all, we've deprecated our Operation.operationName property. It's been replaced by the Operation.kind property. To facilitate this change, each new exchange (or other code) should use the makeOperation utility to create (or copy) operations, as the example in the link shows, since that creates a read-only operationName getter property, which will issue the warning when it's used.

Now that being said, it's possible to see the Operation.operationName property when something console.log's an entire Operation (because that'll cause operationName to be read) or otherwise iterates over all properties. That's because we still have to make the property iterable to support deprecated use-cases and usages of operations like { ...operation }. This will eventually go away in the next major version of @urql/core when we remove the deprecation notice.

I'm not sure what you're referring to with the other example. If you'd like to learn more about the authExchange then we have some documentation on it here: https://formidable.com/open-source/urql/docs/advanced/authentication/
Its authState is not React-only and it's not a global storage. Instead it's the variable name for the internal state of the authExchange utility, so it's safe to use in any environment. The example docs use localStorage but you can replace its usage too since that's configurable.

Could we not make this native so it works without adding this crazy code

I'm not sure if you're referring to authentication in general, but the docs above are our general recommendation and I wouldn't describe them as high-effort and rather a low-effort solution that'll also support refreshing tokens if you need that case supported.

Is it possible to get rid of the warning?

As long as something accesses Operation.operationName, no. This currently includes the @urql/devtools exchange until that's resolved. That being said, the warning will disappear in the next major release, so it's safe to ignore until then, if you're not sure where the warning is coming from.

[tlthiem]

For people wondering why they receive the deprecated warning all the time without ever using Operation.operationName. It might be your outdated authExchange implementation. Like @kitten mentioned, calling { ...operation } iterates through all keys. I had to update my addAuthToOperation using the docs current implementation. Which suggests using makeOperation instead of object spreading madness. Hope this helps someone.