Open aboodman opened 1 year ago
One use case of this is as a source of entropy unique per mutation that, along with a hashing function, could create deterministic / pseudorandom ids. For example,
import { v5 as hash } from 'uuid';
async function mutator(tx, args) {
// Creates 10 uuids that are stable per mutation when played on client and server.
let uuids = Array.from({length: 10}, (_, i) => hash(i, tx.mutationId));
}
The downside is that it exposes a detail of our protocol that people might start to rely on (that it is sequential, that there are no gaps, that it doesn't reset, etc), which constrains what we do with it in the future. ISTM that if what's required is a value that's stable across client and server, the app can simply pick something and pass it in mutator args, be it a counter or random int or guid.
@phritz I'm not sure exposing this is a big deal. It is part of the protocol that a server needs to implement.
Yeah I think it would already be a huge change if the semantics of mutationIDs were to change. Every server would already have to change. The JS API change is small by comparison.
It comes up from time to time that it's useful to have a value that is stable across client and server invocations of a mutation. Exposing
mutationID
would be an easy way to do this.