Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
@urql/[email protected]
Major Changes
authExchange
API, which removes the need for anauthState
(i.e. an internal authentication state) and removesgetAuth
, replacing it with a separaterefreshAuth
flow.The new API requires you to now pass an initializer function. This function receives a
utils
object with
utils.mutate
andutils.appendHeaders
utility methods.It must return the configuration object, wrapped in a promise, and this configuration is similar to
what we had before, if you're migrating to this. Its
refreshAuth
method is now only called afterauthentication errors occur and not on initialization. Instead, it's now recommended that you write
your initialization logic in-line.
Patch Changes
willAuthError
not being called for operations that are waiting on the authentication state to update. This can actually lead to a common issue where operations that came in during the authentication initialization (on startup) will never havewillAuthError
called on them. This can cause an easy mistake where the initial authentication state is never checked to be validSubmitted by @kitten (See #3017)
@urql/[email protected]
Minor Changes
isOfflineError
option to theofflineExchange
to allow it to be customized to different conditions to determine whether an operation has failed because of a network errorSubmitted by @robertherber (See #3020)
updates
config to react to arbitrary type updates other than justMutation
andSubscription
fields.You’ll now be able to write updaters that react to any entity field being written to the cache,
which allows for more granular invalidations. Note: If you’ve previously used
updates.Mutation
and
updated.Subscription
with a custom schema with custom root names, you‘ll get a warning sinceyou’ll have to update your
updates
config to reflect this. This was a prior implementationmistake!
Submitted by @kitten (See #2979)
Patch Changes
stale: true
flag added to them. This is a regression from fix(graphcache): fix loop bug when schema is present #2831 and only applies tocacheExchange
s that had theschema
option setSubmitted by @kitten (See #2999)
invariant
to data layer that prevents cache writes during cache query operations. This preventscache.writeFragment
,cache.updateQuery
, andcache.link
from being called inresolvers
for instanceSubmitted by @kitten (See #2978)
@urql/[email protected]
Minor Changes
maxDepth
andskipType
into thepopulateExchange
, these options allow you to specifythe maximum depth a mutation should be populated as well as which types should not be counted towards
this depth
Submitted by @JoviDeCroock (See #3023)
Patch Changes
@urql/[email protected]
Minor Changes
incremental
property on execution results, as per the specification. This will expand support for newer APIs implementing the more up-to-date specificationSubmitted by @kitten (See #3007)
Accept
header to includemultipart/mixed
andapplication/graphql-response+json
. The former seems to now be a defactor standard-accepted indication for support of the "Incremental Delivery" GraphQL over HTTP spec addition/RFC, and the latter is an updated form of the olderContent-Type
of GraphQL responses, so both the old and new one should now be includedSubmitted by @kitten (See #3007)
Patch Changes
@urql/core
APIsSubmitted by @kitten (See #2962)
hasNext
isn't set. ThehasNext
field is an upcoming "Incremental Delivery" field. When a subscription result doesn't set it we now set it totrue
manually. This indicates to thededupExchange
that no duplicate subscription operations should be startedSubmitted by @kitten (See #3015)
GraphQLRequestParams
utility type from whichGraphQLRequest
s are created in all bindingsSubmitted by @kitten (See #3022)
@urql/[email protected]
Patch Changes
variables
properties optional when a type fromTypedDocumentNode
has noVariables
or all optionalVariables
. Previously this would break for wrappers, e.g. in code generators, or when the type didn't quite match what we'd expectSubmitted by @kitten (See #3022)
[email protected]
Patch Changes
variables
properties optional when a type fromTypedDocumentNode
has noVariables
or all optionalVariables
. Previously this would break for wrappers, e.g. in code generators, or when the type didn't quite match what we'd expectSubmitted by @kitten (See #3022)
@urql/[email protected]
Patch Changes
variables
properties optional when a type fromTypedDocumentNode
has noVariables
or all optionalVariables
. Previously this would break for wrappers, e.g. in code generators, or when the type didn't quite match what we'd expectSubmitted by @kitten (See #3022)
@urql/[email protected]
Patch Changes
Client
provided usingprovideClient
to be used in the same component it's been provided inSubmitted by @kitten (See #3018)
variables
properties optional when a type fromTypedDocumentNode
has noVariables
or all optionalVariables
. Previously this would break for wrappers, e.g. in code generators, or when the type didn't quite match what we'd expectSubmitted by @kitten (See #3022)