"TODO: Fix this. It relies on the query and fragment names matching."

[facebook]

"TODO: Fix this. It relies on the query and fragment names matching."

[yungsters]

Ahh... yes, I apologize greatly for not getting to this before we shipped yesterday. I'll try to get it fixed as soon as possible (unless someone beats me to it with a PR).

[devknoll]

@yungsters What's the ideal behavior? Would it be sufficient to just find the route.queries that includes a particular fragment and keep everything else the same?

[yungsters]

@devknoll Yes, I think that is the ideal behavior. Unfortunately, there is no good way of figuring out which queries in route.queries includes X when all we have to work with is ${Component.getFragment(X)}.

[devknoll]

Ok, two ideas.

1. Super hacky: Run route.queries[y] with a mock component to find the fragment names it's looking for. Maybe parse the result to grab the type and make sure it matches on the component too.
2. A little better: Modify the babel plugin to just stick the possible Xs as metadata on a route.queries[y]

Does one of these sound like an approach you'd take?

[yungsters]

Whoah, idea 1 is super hacky, but I like the way you think. ;)

Another more involved possibility is that we do something like what we did with RelayMutation#getName:

static queries = {
  user: () => Relay.QL`query { user(id: $userID) }`
};

The more I think about it, there really is no semantic value to the keys in queries. What if we got rid of ${Component.getFragment(X)} all together and made it clearer that the query name must match your component's fragment name?

I'm also curious what @josephsavona thinks about this.

[devknoll]

What if we got rid of ${Component.getFragment(X)} all together and made it clearer that the query name must match your component's fragment name?

I like this idea a lot. I like that it makes it more consistent with mutations and gets rid of the (seemingly arbitrary) Component argument, while making it clearer that the query name means something.

In either case, is there a reason we couldn't also just throw an invariant in there to make sure that that every fragment matches a route query? Maybe it'll save some other folks some time ;-)

[josephsavona]

What if we got rid of ${Component.getFragment(X)} all together and made it clearer that the query name must match your component's fragment name?

Yes. We should do that, and also implement @devknoll's idea - root component fragments are automatically added whenever the route key matches the component key, and it's a warning/error if either one has a key that the other is missing.

[devknoll]

Solved by #181