Workflow does data transformation that results in data not coming through

[Mulder]

• Goal: I want to create a workflow which reads data from a specific firestore document. This document has only two elements and both are arrays of strings. One element has 2 items in the array and the other has 598 items in the array. I want my workflow to extract the list of 598 items so that I can do some data manipulation on it (I just want to read the string of arrays from the "photo_exclusions" document in my Firebase database).

• Steps: When I create the query in "Apps", the data returned is correct and it contains two arrays, one with 2 items, the other with 598 items. Creating the EXACT same query to Firebase in Workflows, transforms the data in a non-useful way. I have also added another step (as you cannot transform inside the query of a workflow) to do this: return Object.keys(query1.data).map(k => query1.data[k]) - but the data is still limited to only two items since there's a transformation happening that I do not want to happen.

• Details: The screenshots should explain the issue.

• Screenshots:
  This is the query and the results in "Apps" view (this accurately represents the document as it is in Firebase and is the data I want to access):
  

  

The same query and my attempt to resolve it in the "Workflow" view (this transformed my data in a weird and unexpected way):

[MikeCB]

Hi @Mulder,

It looks like your data is coming back as columnar data in that second screenshot. Retool has build-in helper functions to swap between Object and Array formats. Try something like this in your code1 block to see if it converts it to the format you're expecting:

return formatDataAsArray(query1.data)

There is also the formatDataAsObject() function, which does the opposite.

Documentation is available here.

[bobthebear]

just thought I'd mention, depending on how many times you're calling formatDataAsArray() or the size of the object you pass, it could be slightly more efficient to implement it yourself. the built-in function seems to be designed to work on nested objects giving you slightly more overhead (like variable initialization, data footprint especially if it's recursive, type checking/validation, templatization, ect) which can add up. i don't know if 598 items is a lot or not so you'd probably want to test the differences before using in production... if I had to guess, it'd take more than that to make a big difference, but it all depends on a bunch of stuff so feel free to ignore me unless you're hitting the max workflow run time

const new_obj = {};
for (const [key, value] of Object.entries(data)) {
  new_obj[key] = value[0];
  // console.log(`${key}: ${value}`);
}
return new_obj;