webpack fragment composition from a component perspective about graphql-tag

[stubailo]

This current #import approach requires me to create X number of known parent queries that know which fragments to compose in right then at compile time. Correct?

That's correct, and it's the intended way to use this feature, and you could say GraphQL in general. We've written some blog posts about it: https://dev-blog.apollodata.com/5-benefits-of-static-graphql-queries-b7fa90b0b69a#.m54x4vqj0

I'd lose the somewhat dynamic composition of the Relay way

Relay is also moving away from dynamic composition, in favor of pre-defining these queries in a static way.

why even use fragments with this approach?

Because you get to avoid duplicating the fields a certain component needs if it's used in multiple places. For example:

# Page 1, news feed route
NewsFeed -> PostFeedItem -> PostComments -> Comment

# Page 2, individual post route
PostDetails -> PostComments -> Comment

If you're using the same Comments component in both places, you should define the fields needed by that component in a fragment:

# Fragment for post comments component
fragment PostComments on Post {
  comments(first: 10) {
    ...Comment
  }
}

# Fragment for a single comment
fragment Comment on Comment {
  author { avatar, name }
  content
  postedDate
}

Then, you can use these in both of your queries!

query NewsFeed {
  newsFeedPosts(first: 10) {
    sharedBy { name }
    post {
      title
      ...PostComments
    }
  }
}

query PostDetails {
  post(id: $id) {
     title
     ...PostComments
  }
}

So what's the point of using a fragment to share it? Well, if you edit the Comment component, you can simply add a few fields to the fragment instead of having to modify a bunch of queries.

It's similar to modules and functions in JavaScript - it helps you organize your code and reduce duplication.

[ryancole]

Gotcha. Thanks for the helpful response! 👍