[question] is there a way to render component on partial query response?

[anytimecoder]

Say I have a query with two root fragments:

  static queries = {
    viewer: () => Relay.QL`query { viewer }`,
    user: () => Relay.QL`query { user }`,
  };

One of them takes very long to resolve, another resolves very quickly. I would be happy to render the component partially once the graphql response for the first query is there, but instead Relay is waiting for all the data to arrive for first render.

Is there a way to render component on partial query response?
I saw getFragment().defer() in the source code, which seems to be accomplishing similar goal, but it's not currently supported in OS version.

[josephsavona]

Thanks for asking. You're right that defer isn't currently supported by the default open-source network layer. However, a similar behavior can be achieved using the @include directive and setVariables function. The basic idea is that you would conditionally skip the expensive field:

const FooContainer  = Relay.createContainer(FooComponent, {
  initialVariables: {
    isMounted: false,
  },
  fragments: {
    user: () => Relay.QL`
      fragment on SomeType {
        id  # <-- be sure to fetch at least something at first, even just `id` or `__typename`
        expensiveField @include(if: $isMounted) # <-- don't fetch at first
...

And then in the component's componentDidMount you can call setVariables({isMounted: true}) to fetch the expensive data. This isn't quite as optimal as deferred (the data isn't fetched until after mount), but it works fairly well in most cases.

[anytimecoder]

Thanks for quick response! It's something to work with, but say if I have five expensiveField type of data that I start loading after component is mounted, I would still get them all at the same time, right? Ideally I'd like to show them as they arrive.

[josephsavona]

Yes, the approach I outlined would return all fields marked as conditional at the same time. A more complete version of what you're describing is the defer attribute, which we're tracking in #288. What do you think about closing this issue and consolidating discussion there?

[bchenSyd]

yeah..I used the same approach in my project. Glad that I'm using the 'Official' way!

the drawback is that we will have lots of boilerplate code which I tried to avoid. I still think that deferred query is the right way to go. I'll keep an close eye on this issue