Q: Polymorphic composition

[facebook]

Q: Polymorphic composition

[vladar]

@josephsavona unfortunately it doesn't help in following situations:

1. Trully dynamic components when parent is not aware of all possible children (like Relay.RootContainer)
2. Code splitting - when actual child component is loaded on demand and you don't have reference to it's container at static time

Would be great if Relay could provide some solution for these cases as well as they are fairly common.

[josephsavona]

Great question. Relay has support for this, but it's an advanced feature and so we didn't initially document it. Note that the API is likely to change (but we'll mark it as deprecated before doing so). However, we'd appreciate your feedback on this API and any suggestions you may have.

Current API

Here's how you can construct a container whose child is dynamic based on the current route:

Relay.createContainer(App, {
  fragments: {
    foo: () => Relay.QL`
      fragment on Node {
        ${Header.getFragment('foo')}
        ${route => switch (route.name) {
          case 'RouteA': return ContainerA.getFragment('foo');
          case 'RouteB': return ContainerB.getFragment('foo');
          default: return null;
        }}
      }
    `,
  },
});

In addition to the standard forms of fragment composition documented here, you can also pass a value of the type

(route: {name: string} => ?Fragment;

Basically, a function that accepts an object with a name: string property, and returns an (optional) fragment.

(Proposed) Future API

The future API we've explored for this would use GraphQL directives:

...
foo: () => Relay.QL`
   ${Header.getFragment(...)},
   ${ContainerA.getFragment(...)} @relay(route: 'RouteA'),
   ${ContainerB.getFragment(...)} @relay(route: 'RouteB'),
`

[devknoll]

This is great, thank you! I'll try it out and get back to you.

[devknoll]

Wait... @josephsavona

foo: () => Relay.QL`
      fragment on Node {
        ${Header.getFragment('foo')}
        ${route => switch (route.name) {
          case 'RouteA': return ContainerA.getFragment('foo');
          case 'RouteB': return ContainerB.getFragment('foo');
          default: return null;
        }}
      }
    `,

Wouldn't this only let the composed fragments compose on Node? If ContainerB wanted a User instead, he wouldn't be able to fragment on that, right?

[josephsavona]

@devknoll With the Relay GraphQL spec most types will implement the Node interface, so this would be okay. In your example if RouteA matched, you'd end up with the following (valid) GraphQL:

fragment App on Node {
   ...Header
   ...ContainerB
}
fragment Header on ...
fragment ContainerA on User {...}

[devknoll]

Yup! Just realized that. It looks like there may actually be a bug with graphql-ruby or at least my implementation. Thanks again, and sorry for bothering 😄

[devknoll]

For posterity, the actual query being generated actually looks more like this:

query Dashboard { 
  viewer {
    id,
    ...Header
  }
}

fragment ContainerA on Viewer {
  name,
  id
}

fragment Header on Node
{
  id,
  ...ContainerA
}

This looks like it should be syntactically the same as the above, but I think the first fragment on Node caused graphql-ruby to lose the Viewer type information, forcing it to fall back to a default-implemented resolve_type.

[nodkz]

Referenced to #896
and http://stackoverflow.com/questions/35067685/getfragment-from-a-dynamic-component-in-relay