When I set the parameters directly in the query, like in the screenshot, the query is not called at all. I changed my button event handler for debugging: console.log('Triggering test query'); console.log("Job ID", getOrder.data?.fulfillment_job?.[0]?.id); console.log("Packed at", moment(packedAtInput?.value)?.toISOString()); console.log("Packed by", packedByInput?.value); markJobPackedNew.trigger({ onSuccess: (data) => { console.log('Query succeeded', data); }, onFailure: (err) => { console.error('Query failed', err); } })
But then the debug console only gives back the logged data, it seems that the query itself has not been called:
I also tried inserting the "id"-Parameter with additionalScope, replacing {{transOrderIssues.value.job_id}} with {{id}} and calling the query with markJobPackedNew.trigger({additionalScope: {id: transOrderIssues.value.job_id}}) but this leads to an endless loop that crashes my browser tab in the end:
I found a workaround for the issue by putting a simple Javascript Query in between. So now after clicking the button, a JS Query is triggered that just returns the data that is needed (packed_at, packed_by, job_id). In the Success Event Handler, the other query (the actual database mutation) is triggered, using the results from the JS query like {{returnData.data.packed_at}}. This works, but it seems like an unnecessary step and is the first time I encountered something like this. Usually it is not a problem to use values from transformers or components directly as query parameters or to use additional scope.
Hi @RicardaBSR, great job on figuring out a solution! Just from looking at the info here, my guess is that it has something to do with the transOrderIssues variable. I'm not sure if it relies on some data being fetched that isn't automatically fetched, or if there is something else wrong with it. The console logs you listed don't seem to test it's value, and your other tests are failing at that point. That would also explain why specifically fetching the data before calling the graphql query fixes it.
Ultimately, I don't think your button needs to request that info everytime before calling the graphql query, you just need to make sure all the info (packed_at, packed_by, and job_id) is all defined before pressing the button. So that could mean just calling that javascript query on page load.
Hi @Mike_M, thank you for your answer. transOrderIssues is a transformer that relies on six different queries and one text input. But at the point where the button can be called, the value of the transformer has to be defined, as it is the base for showing a lot of information on the page (including the value of job_id, which was visible when calling the button, and also including the button itself). You are right: in my example of logging the data I used another way to retrieve the job id. But this was because I also tried to exclude the possibility that transOrderIssues might not be resolved at the time the query was called. Both ways to retrieve the job id (getOrder.data?.fulfillment_job?.[0]?.id and transOrderIssues.value.job_id) result in the same behavior: the value is defined when logging it, but somehow the GraphQL query is not called. So far, using the JS Query in between is the only way for me to make this work.
As for the values of packed_at and packed_by, they must be defined before calling the button, as it would otherwise be disabled.
