Relay: Fragment metadata

[decebal]

What does fragment metadata means & what is it supposed to set it ?

Apparently there are decisions made in relay-runtime based on this metadata, but in my case it's not set and I haven't got a clue on how to go about having it set or setting it myself.

[kassens]

The big goal of the Relay Modern rewrite was to move computation where possible from runtime to compile time. This shouldn't just work for the build-in stuff, but ideally we would also enable advanced users to write plugins that live not only in the runtime space, but also do work at compile time. The parts of the plugin that are plugged into the compiler could leave metadata on fragments for the runtime part.

We currently have one build in "plugin", the @connection annotation that allows one way of connection management that we use at Facebook and the old relay supported exclusively.
Some of the APIs around refetching and paginating got a bit more verbose in Relay Modern and I hope to reduce this again going forward. In fact, I already added a bit of metadata for pure modern mode to @connection to make a few of the methods optional to include. The compiler part of that plugin lives here: https://github.com/facebook/relay/blob/3a099fdd27505ce0e8811f2d2d22afab12ea5d2a/packages/relay-compiler/handlers/connection/RelayConnectionTransform.js#L184-L189

Going forward, I hope we can even synthesize queries into the metadata similar to what the old core did dynamically at runtime. The best of both worlds: concise API similar to the classic core AND no runtime overhead of extra bookkeeping and query generation!

[decebal]

thanks for the explanation @kassens .

I have some issues using the connection and relay directives in modern relay, so I was wondering if you could point out a sample setup.

[janicduplessis]

@decebal Are you using compat mode with relay classic environment? I've noticed I needed to specify a lot more fields for it to work in that case. When switching to relay modern context I was able to get rid of them.

Here's an example pagination container that worked for me with classic env.

createPaginationContainer(
    Screen,
    graphql`
      fragment Screen_viewer on Viewer {
        myConnection(
          first: $count,
          after: $cursor
        ) @connection(key: "Screen_myConnection") {
          edges {
            node {
              id
            }
            cursor
          }
          pageInfo {
            hasNextPage
            endCursor
          }
        }
      }
    `,
    {
      getConnectionFromProps(props) {
        return props.viewer.myConnection;
      },
      direction: 'forward',
      getFragmentVariables(prevVars, totalCount) {
        return {
          ...prevVars,
          count: totalCount,
        };
      },
      getVariables(props, { count, cursor }) {
        return {
          count,
          cursor,
        };
      },
      query: graphql`
        query ScreenPaginationQuery(
          $count: Int!,
          $cursor: String
        ) {
          viewer {
            ...Screen_viewer
          }
        }
      `,
    },
  );

[decebal]

hi @janicduplessis, my setup is similar with the only difference that my schema does not have a viewerthat is relayed upon, I have tried what you had there and worked on a sample, but when I get rid of the viewer and use the fragment directly (so the query becomes:

query: graphql`
        query ScreenPaginationQuery(
          $count: Int!,
          $cursor: String
        ) {

            ...Screen_viewer

        }
      `,

) I found myself a little bit confused on how to use the data props on my component after that modification as the properties turn up to be null :( .

Also you have not named your fragment, is that for a specific reason ?

[bondanherumurti]

@janicduplessis hi jan, your settings is actually similar to mine, but my load more is not working, could you checkout here https://github.com/facebook/relay/issues/1789

Cheers