clientMutationId -> clientSubscriptionId?

[taion]

I'm curious why this library uses clientMutationId to identify subscriptions. Looking at facebook/relay#541, it seems like the original sketch called the field clientSubscriptionId. I think the latter would make more sense.

[taion]

It looks like Relay expects it to be clientSubscriptionId specifically: https://github.com/facebook/relay/blob/1976109901487189407c86b7c2fdf68e85523ad7/scripts/babel-relay-plugin/lib/RelayQLPrinter.js#L274-L275

[edvinerikson]

So the reason for having clientMutationId was because in earlier versions of Relay, the mutation API didn't check if this field was present or not is just assumed it was therefor it would throw an error.

I think that we can remove it or rename it to clientSubscriptionId. I am not sure it will provide any value for us anyway since clientMutationId is only used for applying optimistic updates which subscriptions doesn't have.

But... to be more extensible I think we should always pass it as a input argument so that users can query it if they want.

[taion]

Well, the GraphQL server will complain if it gets an unsupported input field.

I want to figure out how much of the subscription map management can reasonably be done at the library level (i.e. here) v. at the network layer level.

It's possible that this field is just entirely useless and should go away completely. My first cut implementation is making no use of it.