Match fileCreate result IDs to our data

[johncmt]

The fileCreate mutation accepts an array of FileCreateInput.  When sending multiple files at once, what is the recommended way to match the array of File objects in the response to the data we sent?  

The ordering of the results in the returned array does not match the order of the objects we sent.  We can use the alt value in the response, but that is a flimsy way of matching and does not protect against scenarios where two files in the same upload may have the same alt text.  

Ideally, each record in the response array would have an index number property corresponding with the upload order. 

Bulk mutation has this with __lineNumber.  In that sense, why not design fileCreate as a bulkMutation using Jsonl rather than using an input JSON array?  

Thanks!

[Stephan_Leroux]

Hey John!

Thanks for the feedback on the fileCreate mutation. When working with large sets of files, it can be tedious to have to full scan the response to do GID matching with the original inputs here given the lack of strict ordering in the JSON response. Current suggestion would be to do additional bookkeeping for now on the request/response IDs but we're actively working on a better solution.

> Bulk mutation has this with __lineNumber.  In that sense, why not design fileCreate as a bulkMutation using Jsonl rather than using an input JSON array?  

Great suggestion re: JSON Lines! We'll take this back and see what we can do as part of our effort to make the API more ergonomic.

[johncmt]

Thank you for your response, Stephan!

I'd be curious to hear more about how you envision using request/response IDs.  Since we're sending a batch of files to fileCreate in an array, there is only a single request/response ID.  We could send each fileCreate response one at a time, but that would be very inefficient from a network traffic perspective.  

Really need either a) an ordinal/__lineNumber added to each object in the response array or b) fileCreate enabled for bulkMutation.  But for b) it seems like you'd want another mutation (i.e. fileCreateSingle) so that the input is not an array.

Anyhow, we are using alt text matching for now.  Not perfect, but at least a readily available workaround. 

[Stephan_Leroux]

>  Anyhow, we are using alt text matching for now.  Not perfect, but at least a readily available workaround. 

Interesting - how are you doing alt text matching today? (Agreed - not the most ideal situation!). Are you precomputing a unique string value ahead of the fileCreate mutation and then using that as a key lookup in the response array?

[johncmt]

You are correct on the alt text matching.  We are ensuring each image file has unique alt text.  In our case, it follows the format [Color Name]: [View Name].  For example, "Navy: Main View", "Navy: Second View", "Navy: Model View", etc.  We are then matching those text values to the alt value in the API response, since there aren't any other unique fields in the response we could use.  In general, we try to avoid doing matching on free-form text properties.  Much prefer using unique IDs or ordinals (such as __lineNumber) that we can guarantee to be correct.  

Ironically we had already started creating unique alt text on the image files to work around another issue: the productSet mutation does not provide a way to set the swatch color or image, which would seem to be a logical addition to OptionValueSetInput.  This prevents us from being able to use the new swatch capabilities since we have too many SKUs to do this manually.  So instead, we created our own swatch color input via metafield, then modified the product display page to show the images for each variant by analyzing the custom alt text.

I created a forum post about adding swatch info to OptionValueSetInput:

https://community.shopify.com/c/shopify-discussions/how-to-set-option-value-swatch-via-productset-mu...