7.0.0
Commits: v6.0.0...v7.0.0
Breaking
-
Variables are no longer set in Relay Context when using a
QueryRenderer
. This means that any product code that was relying on reading variables fromRelayContext
will 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-runtime
no longer exportscreateRelayNetworkLogger
. This logger is being replaced with event based logging on theEnvironment
which 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
Store
constructor changed; specifically the second argument to the constructor is now an options object. Any product code directly constructing aStore
and passing a second argument will need to be updated. -
Relay Compiler no longer relies on
graphql-js
for 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. -
@defer
is no longer allowed on inline fragments, since we can’t communicate a loading state with Suspense when used on an inline fragment.@defer
is now only supported on fragment spreads.
Added
- RelayCompiler: added a new directive (3dd79e8)
@DEPRECATED__relay_ignore_unused_variables_error
to suppress errors that were surfaced after we've migrated from GraphQLNoUnusedVariablesRule
to RelayIRTransform validation. GraphQLNoUnusedVariablesRule
was 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.
Improved
- Relaxed the constraint for
@refetchable
directive on a fragment: we no longer enforce that the argument for thenode
field is calledid
; it can be called anything as long as it’s anID
type. - Developers can now select the
__id
field anywhere that__typename
can 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 anid
. 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.
Fixed
- 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
null
as default value of enum: 6946e85 - Fix display names for containers.
- Fixed
@refetchable
connection 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)
Misc
- Upgraded React peer dependency to
16.9.0
. - Upgraded
babel-preset-fbjs
to 3.3.0 - RelayCompiler: We've changed the field
type
andtypeCondition
in GraphQL IR types to use Relay internal representation of GraphQL type (2606f32). Before this change, we were directly usinggraphql-js
type instances. But eventually, our goal in Relay compiler is to get rid of the dependency on thegraphql-js
schema 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.
Experimental
- Several performance improvements to the internal implementation of
useFragment
were shipped. - 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
useQuery
hook; this might happen whenuseQuery
starts a long-lived request, e.g. to poll for real time data. - Fixed issue in
useQuery
to 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
useBlockingPagination
. - Fixed pagination with Relay Hooks when using fragments that contain
@argumentDefitions
. - Pagination with Relay Hooks is now allowed even if server returns value for
hasNextPage
as false. - 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.