Allow duplicate graphql calls if variables are different#1244
Allow duplicate graphql calls if variables are different#1244indykoning wants to merge 1 commit intomasterfrom
Conversation
| methods: { | ||
| async mutateFn() { | ||
| if (this.running) { | ||
| if (this.running && JSON.stringify(this.data) === JSON.stringify(this.runningVariables)) { |
There was a problem hiding this comment.
This could be improved with canceling the previous request, or returning the current request depending on data changes.
But this would require a much larger structural change with the fetch requests, and the way functions are handled here:
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#canceling_a_request
This has been added to: RAP-1230
| let variables = this.data, | ||
| query = this.query | ||
|
|
||
| this.runningVariables = JSON.parse(JSON.stringify(this.data)) |
There was a problem hiding this comment.
As we're only really using this stringified, is it worth it just for the code consistency to end up doing JSON.stringify(JSON.parse(JSON.stringify(this.data)))?
The performance hit is essentially neglegible so it doesn't really matter too much, but it doesn't feel right to me that we're juggling the json around like this.
Perhaps we could consider a different approach as well. We already have a watcher for the variables data changing---what if we just increase a counter every time the variables are changed, and use that to compare with?
| name="{{ $type }}_postcode" | ||
| v-model="variables.postcode" | ||
| v-on:change="$root.$nextTick(() => window.$emit('postcode-change', variables))" | ||
| v-on:change="(event) => $root.$nextTick(() => window.$emit('postcode-change', variables, event))" |
There was a problem hiding this comment.
is this the best way to pass the event along? How would this look on the postcode package side?
2 participants
In: #740 this check was introduced.
It fixed accidental double clicks causing duplicate requests.
But it also broke the same graphql component sending a request with different variables, which would now get short circuited without sending a request to update the data.
This would for instance cause issues with postcode modules updating the address.
As the change event on a postcode field would trigger the mutate for the updated postcode, at the same time the postcode module would update the street and city.
Attempting to mutate it would result in nothing since the previous mutation has not finished yet.
When this is approved i will roll this change out to the other packages (postcode-change event), as well as the 4.x branch
ref: RAP-1827