Query composition

[stubailo]

Tied in with #80

Pinging @abhiaiyer91 who said he had some ideas and talked to @helfer

[stubailo]

Never mind - Abhi was talking about resolver composition. False alarm!

[stubailo]

To add more detail to this issue, this includes:

1. The ability to declare fragments on individual components
2. The ability to merge those fragments into one big query to reduce the number of roundtrips on first load
3. The ability to have per-fragment variables which are intelligently refetched a-la-Relay

This is important to be able to co-locate your data requirements with the components, without having a performance impact on your app's first load.

[batjko]

Would this include some abstraction from the GraphQL String notation? I mean I'm not sure I'd want a full-blown ORM here, and perhaps a simple String is still the most efficient way, but if we're just talking about small fragments, that then need to be composed in some way, I wonder if an Object-based API might be better here?

[stubailo]

Would this include some abstraction from the GraphQL String notation?

I feel like GraphQL query strings are the best part of the whole system, but perhaps it would be a good idea? What would be the benefit of an abstraction other than fragment strings?

[batjko]

I'm thinking of scenarios where one would want to dynamically create these fragments from a bunch of options at runtime. Yes, we could just use string interpolation, and perhaps that's best and I'm thinking too traditionally, here.

[stubailo]

Oh that's what the skip and include directives are for! I think the best practice is to never use string interpolation on queries, which would be pretty easy to check with a longer.

[stubailo]

*linter

[jbaxleyiii]

I thinking keeping Apollo 100% graphql spec for query formation (aka just strings) is the best move. It reduces the barrier to entry to the project and we can help mlve the spec forward if / when needed

[batjko]

that's what the skip and include directives are for

Yes, I suppose. That would work for me. However, the approach assumes a lot of knowledge of GraphQL syntax. I know developer friendliness will be tackled later, but providing an API for these things might help those who are new to the GQL spec and just want to make use of Apollo's reactive data etc.
Just a thought.

[smolinari]

Although I have little to say here, I would also put forward a 👍 to sticking to the specs.

Scott

[stubailo]

Personally I feel like skip and include aren't much harder than string interpolation with an if statement, plus we can more easily do query validation if there isn't interpolation everywhere.

[batjko]

@stubailo Yes, fair point.
I really have no preference here, just wondering about best practices. Happy to jump on board.

[tlvenn]

Is there any update / timeline / milestone for that feature ? This is one of the strong point of Relay, should Apollo Client be able to provide query composition, I expect it will be a huge help to increase adoption.

[stubailo]

@tlvenn: @Poincare is working on it next week!

[tlvenn]

That's great news, thanks for the update !

[Poincare]

This was merged some time ago with createFragment within #343. We can close this issue at this point, probably.