react-relay v3.0.0 Release Notes

Release Date: 2019-02-23 // about 5 years ago
  • 3.0.0

    Commits: v2.0.0...v3.0.0

    💥 Breaking

    • ✂ Removed Relay Classic and Compat.
    • 🚚 react-relay/modern has been moved to react-relay/.

    🛠 Fixed

    • 🛠 Fixes an issue with schemas with internal enum values (ie, printing as a string but internally represented as an int), these enum values will now correctly print as the enum name instead of the internal value. #2638
    • 🔄 Changes commitMutation() to call onCompleted with null errors if there were no errors (instead of an empty array). c80a0fa
    • 🛠 Fixed issue with sequential optimistic mutation payloads: 55ce137
    • Disabled a built-in graphql-js validation rule (checking that variables are used in allowed positions) in the compiler which could incorrectly report errors when an argument in the @arguments directive conflicted with the nearest parent field argument. Relay-compiler already implements the same validation internally and is aware of @arguments/@argumentDefinitions.

    👌 Improved

    • ✂ Remove validateNames option in compiler which was always true.
    • Flow types are properly generated for refetchable queries.

    Experimental

    • ➕ Added partial support @stream and @defer in QueryExecutor. Note that this feature is experimental and subject to change. No public API is provided yet.
    • ➕ Added support for using @module outside of @match, enabling new use-cases for data-driven dependencies. No public API is provided yet.
    • ➕ Added fragment ownership under a feature flag. Fragment ownership is a new constraint that we're rolling out in the internal model of Relay where every instantiation of a fragment at runtime (i.e. a fragment for a given dataID) is associated with an operation that "owns" it; this operation will usually be a query. This is similar to how fragments work in GraphQL, where they need to be a part of a query in order to actually be fetched. This has a few benefits:
      • It allows us to stop relying on React Context to propagate query variables through the tree (which are needed in order to read fragments), and instead can be accessed directly on the fragment owner associated with a fragment.
      • Not using React Context also allows fragment results to be context-free and allows us to deal better with complicated edge cases like nested context (which occurred with refetch and pagination containers). E.g. if you pass a fragment reference from "above" a RefetchContainer/PaginationContainer/QueryRenderer and try to use it somewhere within one of those, it will probably not do what you expect since the variables will be wrong. With ownership, you always get the right variables.
      • This in turn also allows us to specify behavior like refetching (which has historically been confusing) more precisely: refetching a fragment simply means reparenting it under a new owning operation.