Best answer

How to get user input for an array of objects containing key-value pairs?

  • 9 October 2020
  • 6 replies
  • 3393 views

  • Anonymous
  • 0 replies

Hello!

I have registered a development app relating to creating document metadata in our app (Mendeley) and am able to make simple requests to our POST endpoint.

I.e., I accept a user input field called title and this successfully translates into a payload of {title”: “userinputhere”}

So far so good.

What I’m trying to do now is design the Zapier input such that the user is able to specify an array of objects with multiple attributes, specifically

"authors": [
{
"first_name": "userinputhere",
"last_name": "userinputhere",
},
{
"first_name": "userinputhere",
"last_name": "userinputhere",
}
],

Note that there may be any number of authors of a document, and the idea would be that a user could systematically identify author values to use with a pattern match step to extract author names from e.g. a formatted list of references in a text file.

Well, as a non-developer here I am so stuck 😀

A few questions:

  • This doesn’t seem to be possible in the visual Input Designer?
  • If I am to take the leap and convert this project for use with the CLI, I guess there’s no way going back and forth between the CLI tool and the Input Designer?
  • If I am to use the CLI to get this input working, could anyone help guide me on a pattern or sample code where someone has been able to set up Zapier input for an array of objects with multiple attributes, per the above?

Thanks for any contributions you have!

icon

Best answer by Zane 12 October 2020, 17:31

View original

This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

6 replies

Userlevel 7
Badge +10

Hi @mendomat 

I’m moving this to the “Developer Discussion” board as this should get more eyeballs there.

Userlevel 7
Badge +9

Hi there, the first question is how you expect the authors to be emitted from the triggering app, and passed to your action.  If the authors are in an array in the data that the user is mapping to your action in the Zap Editor, then what you are working with is what we call a “line item”.   Define a line item group and the child fields, and Zapier expects that an array of things will be passed in at run time.  You can do this either in the UI or in the CLI.  

https://platform.zapier.com/docs/input-designer#how-to-add-a-line-item-group

https://zapier.github.io/zapier-platform/#nested--children-line-item-fields

 

If the source data contains an arbitrary number of author objects, not in an array - this is trickier.  There’s not a way to allow the user to statically map an array of objects in the editor today.

And to your question about moving between the UI and CLI.  It’s super easy to move your project from the UI to the CLI, but it’s basically an eject operation.  The CLI allows for a lot of flexibility, and creates a project that the UI can’t parse and understand.  You can come back to the UI and resume work there, but you’ll lose any changes you made in the CLI managed versions.

Userlevel 7
Badge +12

Hi @mendomat,

You should be able to do that in Visual Builder by adding a Line Item Group:

  1. Set the Line Item Group Key to authors.
  2. To add a field to author object, click on Add Line Item.

When the zap runs, line items will be passed to your action as an array of objects. Each object will contain the values for those line item fields you added. I hope this helps you solve your problem!

Please note that once your integration has been converted to a CLI app, you won’t be able to go back to the Visual Builder.

 

 

 

 

 

Hi there, the first question is how you expect the authors to be emitted from the triggering app, and passed to your action.  If the authors are in an array in the data that the user is mapping to your action in the Zap Editor, then what you are working with is what we call a “line item”.   Define a line item group and the child fields, and Zapier expects that an array of things will be passed in at run time.  You can do this either in the UI or in the CLI.  

https://platform.zapier.com/docs/input-designer#how-to-add-a-line-item-group

https://zapier.github.io/zapier-platform/#nested--children-line-item-fields

 

If the source data contains an arbitrary number of author objects, not in an array - this is trickier.  There’s not a way to allow the user to statically map an array of objects in the editor today.

And to your question about moving between the UI and CLI.  It’s super easy to move your project from the UI to the CLI, but it’s basically an eject operation.  The CLI allows for a lot of flexibility, and creates a project that the UI can’t parse and understand.  You can come back to the UI and resume work there, but you’ll lose any changes you made in the CLI managed versions.

Indeed it is an arbitrary number of author objects. I guess I will have to get my hands dirty in the CLI… wish me luck!

Userlevel 7
Badge +9

Indeed it is an arbitrary number of author objects. I guess I will have to get my hands dirty in the CLI… wish me luck!

 

The issue here is less to do with unexposed functionality in the UI-based builder as it is with a limitation in the Zapier field mapping editor and platform/engine itself.  Again the issue is not that there’s an arbitrary number of objects in the data being mapped, but there’s an arbitrary number of objects not in an array.  

The only way around this that I can think of is to create some set number of line item groups, Author 1, Author 2, Author 3, Author 4.  And that would work - you can map a single object to a line item input.  It will get emitted as an array of one element.  The limitation is that you’ll have to hard-set a maximum number of authors.  

You can effect this in the UI or the CLI.  I’m not sure the CLI is going to provide special powers to address this.  I don’t want to discourage you from moving to the CLI - it’s a superior tool once you’re over the learning curve.  But I don’t want you to get there and realize it didn’t do what you hoped.  

Perhaps another community member has another clever way to address this.  

I think I see. I will have a play around and see what I can do when I next have a pocket of time. Thanks for your input!