Remove clientMutationId

[steida]

We should figure out how to remove it. I'm pretty sure it's just a fb-ism. Can you open an issue?

https://twitter.com/kassens/status/903031923827654658

cc @kassens

[steida]

It's somehow used by the code because when I tried to use constant, React key was the same...
https://www.graph.cool/forum/t/clientmutationid/426/3?u=daniel_steigerwald

[omerzach]

Is there any hack possible to avoid all the boilerplate of parsing this ID and returning it again in every mutation? E.g., can I just include a random string in my mutation responses?

[steida]

https://github.com/este/este/blob/0dce17f0553a0ecb0df0c378695192cd0351e20b/components/withMutation.js#L8

[steida]

I think it was caused by graph.cool

[omerzach]

Why was this closed? clientMutationId is still all over Relay. If it's not necessary it would be really great to remove it.

I'm happy to try to submit a PR removing it if someone can confirm it's unnecessary. +@leebyron

[steida]

@kassens told me, that it should be removed from Relay. Now it must be used, otherwise, Relay will generate wrong ID for an item with the same text for an unknown reason.

[steida]

Random clientMutationId must be passed to Relay and defined in GraphQL model as well.

@kassens Please check this. That's what happens when I add two items with the same text. This is Relay bug.

[taion]

this is gated on #2349

[taion]

it's essentially the same thing as that PR

[alloy]

This is fixed now by #2349 right? (Re-open if not.)

[ersinakinci]

So is this line from the docs inaccurate?

Mutations

Relay uses a common pattern for mutations, where there are root fields on the mutation type with a single argument, input, and where the input and output both contain a client mutation identifier used to reconcile requests and responses.

[sibelius]

Feel free to update

[ersinakinci]

@sibelius, I saw your response on the other thread, but I don't understand enough to change the docs. The only info I have is basically that one sentence in the doc, a couple of half-answered SO posts suggesting that the "client mutation identifier" means "put a field called clientMutationId into the schema," and the title of the PR that I linked to.

To distill my general confusion into a some concrete questions:

• What are some concrete examples of how clientMutationId is used, within Relay and externally? The docs simply state that it's used "to reconcile requests and responses," but what does that actually mean?
• What are some concrete examples of how the generated root id is used, within Relay and externally? The title of Remove the clientMutationId requirement by creating a new root id for each executed mutation #2349 implies that clientMutationId has been replaced by some kind of "root id" mechanism, but do root id's serve the exact same purpose as clientMutationId or do they also take on some other roles?
• More generally, what is a "root id" and what does it mean that a new "root id" has been created for each executed mutation?
• If root id's have succeeded clientMutationId's, it doesn't sound like they've completely supplanted them. When would you use a clientMutationId over relying on the default root id mechanism?
• Does supplying a clientMutationId field on the input type and/or payload type somehow "override" the root id?

If you could help me answer these, I could take a stab at updating the docs.

[sibelius]

What are some concrete examples of how clientMutationId is used, within Relay and externally? The docs simply state that it's used "to reconcile requests and responses," but what does that actually mean?
clientMutationId can be used on server to make sure you don't send the same request twice

clientMutationId is the same as an idempotency key (https://stripe.com/en-br/blog/idempotency)

What are some concrete examples of how the generated root id is used, within Relay and externally?

Relay Store (https://medium.com/@sibelius/relay-modern-the-relay-store-8984cd148798) uses normalized data to cache records, when doing a mutation without clientId, the "key" to store the mutation inside the store will be auto generated, so you can access mutation data inside updater

More generally, what is a "root id" and what does it mean that a new "root id" has been created for each executed mutation?
QueryType is an example of root id (

relay/packages/relay-runtime/store/RelayStoreUtils.js

Line 203 in 62fd9d3

ROOT_ID: 'client:root',

)

If root id's have succeeded clientMutationId's, it doesn't sound like they've completely supplanted them. When would you use a clientMutationId over relying on the default root id mechanism?
This won't accept anything on client side, only server for idempotency

Does supplying a clientMutationId field on the input type and/or payload type somehow "override" the root id?
@robrichard can explain better this change

[robrichard]

@earksiinni @sibelius this is my understanding of the clientMutationId

clientMutationId was a requirement for Relay Classic. As far as I'm aware it is not required for Relay Modern and all references in the docs should be removed to avoid confusion.

I think the title for #2349 is causing some confusion. There was a bug in relay where mutations with identical input caused a conflict in the store. One possible workaround for this bug was to use a clientMutationId like was used in Relay Classic, but that issue is fixed now.

The root id is the id relay generates to store response data in the store. By making it dynamic, instead of static, we no longer have the issue of mutations conflicting. It's an implementation detail of Relay, not something a developer needs to do as part of their mutation code.

Hopefully this clears things up