Update dependency react-relay to v18 #8477
Open
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 contains the following updates:
17.0.0
->18.1.0
Release Notes
facebook/relay (react-relay)
v18.1.0
: Version 18.1.0 Release NotesCompare Source
Following up from our v18.0.0 release last month, v18.1.0 provides a number of fixes and improvements, adds some new experimental APIs, and ships some long-running experimental features as stable.
Relay Resolvers are now stable
For the past several years we've been iterating on Relay Resolvers which provided a structured and typesafe way to model client state and derived data in your GraphQL graph. As of this release, Relay Resolvers are enabled by default and no-longer experimental. As part of this stabilization we shipped fixes for Relay Resolvers when used with TypeScript and fixed a few edge cases related to how errors encountered by resolvers are handled.
Improvements to error @catch
We released
@catch
in v18.0.0 and are very excited about the capabilities it enables. Check out Itamar Kestenbaum's GraphQL conf talk about it here: Build Confidently: How @Catch and Error Handling Pave Way in Field Nullability.Since that release we've made a few improvements:
@catch
directive that are marked as@semanticNonNull
in the schema now generate non-nullable TypeScript/Flow types. See semantic nullability.@catch
no-longer include the error message. This is because GraphQL error messages are generally not safe to show to users. These error messages can still be accessed by the field logger provided to your Relay Environment. In the future we plan to let users opt into allowing safe error messages through to product code.Compiler Error Reporting
We've improved how errors are reported by the Relay compiler to ensure we report as many errors as possible, and each error includes sufficient context.
New "Copy Operation" VSCode command
Our VSCode extension now includes a command to quickly copy the full text of a query directly from within your editor.
Experimental APIs for reading fragment data outside of React
In some cases it can be useful to read a fragment outside of a React hook. However, doing this requires handling a number of concerns.
@defer
or Relay Resolver suspense).@throwOnFieldError
,@required(action: THROW)
)To enable users to read fragment data while correctly handling these cases, we've added two experimental APIs:
observeFragment
: Read a fragment as a stream of states where each state might be loading, error, or value.waitForFragmentData
: Read a fragment as a promise which will resolve when data is available, or reject if an error is encountered.Docs
Thanks to members of our community for submitting pull requests to improve our docs:
Improvements
Experimental
We are always continuing to evolve and improve Relay. These changes are part of features or implementations which are either in progress or are being experimented with internally.
v18.0.0
: Version 18.0.0 Release NotesCompare Source
With version 18, the Relay team at Meta and our community of contributors have made several significant improvements to Relay:
@alias
released as stable@catch
to detect and granularly handle field errors@throwOnFieldError
and@semanticNonNull
to avoid having to handle the nullability of fields which are only null in the case of error.Read all about them in more detail below:
Breaking Changes
Improved validation of field and fragment arguments
Previously we were not correctly type-checking arguments passed to client-defined fields, such as Relay Resolvers and Client Schema Extensions. This new release adds that validation. If you need to opt out of this validation for any reason, you can enable the
disable_full_argument_type_validation
compiler feature flag.Major features
@alias fragment aliases released as stable
Aliased fragments are a Relay feature that lets you access fragments spreads and inline fragments as named properties. This can be especially helpful for fragments which might be conditionally fetched due to
@skip
/@include
or type conditions which might not match. With@alias
these fragments get typed as nullable properties allowing you to check at runtime if they've matched or not before trying to use the data.Read more about @alias
@catch
@catch
, enabled by default will let you check at runtime if a field errored. This can allow you to disambiguate between true nulls returned by your server, and fields which are null due to field level errors.Read more about @catch
@throwOnFieldError
@throwOnFieldError
can be added to fragments and queries and will cause any field errors within that fragment/query to throw when read. This ensures that all null values you encounter are true nulls as returned by your field resolvers on the server, and not field level errors that have been coerced to null.Read more about @throwOnFieldError
Semantic Nullability
@throwOnFieldError
unlocks a powerful new feature when combined with a schema that has fields annotated with@semanticNonNull
.@semanticNonNull
can be added to fields which have been made nullable in the schema only to enable more robust error handling, but are not expected to return null expect in the case of errors.Within fragments or queries annotated with
@throwOnFieldError
, fields annotated with@semanticNonNull
will be typed as non-nullable. This has the potential to dramatically reduce the number of null checks you need to perform inside your product code, while also making your product code more "correct" by treating all field errors as explicit errors.Read more about Semantic Nullability
Relay Resolvers can now have access to context
Thanks for Mark Polak and Drew Atkinson from Microsoft, Relay Resolvers can now be configured to accept a shared context object, similar to standard GraphQL resolvers.
Pull Request
Read more about Resolver context
Ability to opt out of Relay Compiler source control integration
Thanks also to for Mark Polak from Microsoft, the Relay compiler config now supports the option
"noSourceControl": true
which will ask the Relay compiler to not automatically try to add/remove files from Git or Mercurial.Pull Request
Editor Integration Improvements
Thanks to Tobias Tengler, Relay's editor support now includes:
Additional runtime logging integrations
Additional Improvements
D542067
: Validate edgeTypeName argument points to an existing type by Amy HwangDocumentation Improvements
Miscellaneous
Experimental Changes
IdOf
by Tianyu YaoAnd more
There were over 100 additional commits since our last release which have been omitted from this doc
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.