Variables are no longer set in Relay Context when using a
QueryRenderer. This means that any product code that was relying on reading variables from
RelayContextwill break. If you need to access the variables that were set at a query root, the recommended approach is to manually pass them down through the component tree in product code.
Removed old RelayNetworkLogger, and
relay-runtimeno longer exports
createRelayNetworkLogger. This logger is being replaced with event based logging on the
Environmentwhich will allow us to have richer and more contextual events logged with more detail on what's going on. Wrapping the actual network request doesn't work well as some "requests" might never actually end up on the network when they can be fulfilled completely from the store.
The constructor signature of
Storeconstructor changed; specifically the second argument to the constructor is now an options object. Any product code directly constructing a
Storeand passing a second argument will need to be updated.
Relay Compiler no longer relies on
graphql-jsfor query validation. Most of the validation rules we used previous are now part of the RelayParser itself, while the remainder and implemented as transforms (15e8d22). Additionally, we've removed the concept of RelayIRValidations (da01bf3), which ran after IR transformation.
@deferis no longer allowed on inline fragments, since we can’t communicate a loading state with Suspense when used on an inline fragment.
@deferis now only supported on fragment spreads.
- RelayCompiler: added a new directive (3dd79e8)
@DEPRECATED__relay_ignore_unused_variables_errorto suppress errors that were surfaced after we've migrated from GraphQL
NoUnusedVariablesRuleto RelayIRTransform validation. GraphQL
NoUnusedVariablesRulewas not aware of the difference between root (operation) variables and local fragment variables (defined by @argumentDefinitions) - because of that, it was considering the local fragment variables that have the same name as the root variable as used and did not report the violation. But in Relay compiler, we know this distinction, and we already keep track of the root variables and can report those invalid cases. Unfortunately, this revealed multiple violations that weren't possible to fix without product team involvement. For this purpose, we added a directive that can be used to temporarily suppress the error while teams fix their queries.
- Relaxed the constraint for
@refetchabledirective on a fragment: we no longer enforce that the argument for the
nodefield is called
id; it can be called anything as long as it’s an
- Developers can now select the
__idfield anywhere that
__typenamecan be selected, in order to fetch the internal cache key of an entity. The primary use-case for this is updating records that don’t have an
id. Before, updating or deleting such entities would require writing an updater function that traversed from the nearest strong entity (w an id); now, developers can directly target records with e.g.
store.get(record.__id)in an updater function.
- RelayCompiler: Usage of $variables in Complex objects (or as List Items) is now disabled by RelayParser: 6946e85 This was already unsupported, but Relay previously threw an error later in compilation.
- MockPayloadGenerator: allow
nullas default value of enum: 6946e85
- Fix display names for containers.
@refetchableconnection metadata for custom handlers.
- Fixed missing field handler behavior for plural linked fields.
- Fixed getRefetchMetadata to handle both commonjs and esmodules. (#2875)
- Fixed printing require module dependency in generated artifacts. (#2861)
- Upgraded React peer dependency to
- RelayCompiler: We've changed the field
typeConditionin GraphQL IR types to use Relay internal representation of GraphQL type (2606f32). Before this change, we were directly using
graphql-jstype instances. But eventually, our goal in Relay compiler is to get rid of the dependency on the
graphql-jsschema representation and use a faster/less memory intensive representation of the schema. We also build a Schema wrapper: 9e6d919 - that should help us during this migration.
- Several performance improvements to the internal implementation of
- Fixed issue to stop tracking mutations as in flight in the RelayOperationTracker when applying the optimistic update; this caused issues with suspending unexpectedly.
- Fixed issue to stop tracking GraphQL subscriptions as indefinitely in flight in the RelayOperationTracker; instead, subscriptions should only be tracked as in flight when they’re waiting for incremental or module payloads. This caused issues with suspending indefinitely in some cases.
- Fixed issue to correctly dispose of ongoing requests when unmounting a
useQueryhook; this might happen when
useQuerystarts a long-lived request, e.g. to poll for real time data.
- Fixed issue in
useQueryto not suspend indefinitely when server response doesn’t return all of the requested data. This might occur for example when making selections on abstract types.
- Fixed re-establishing store subscriptions when using
- Fixed pagination with Relay Hooks when using fragments that contain
- Pagination with Relay Hooks is now allowed even if server returns value for
- Several improvements to new experimental representation of connections.
- Temporarily exposed new option for useQuery:
renderPolicy_UNSTABLE, which determines whether data should be eagerly or lazily rendered.