Using varargs in Sync tables

I’m trying to add a pair of varargs params to a dynamic sync table. I get this error message when trying to compile the pack:

Pack metadata failed validation: [{“path”:“syncTables[0].getter.varargParameters”,“message”:“Sync table formulas do not currently support varargParameters.”}]:
Error in field at path “syncTables[0].getter.varargParameters”: Sync table formulas do not currently support varargParameters.

@Eric_Koleda any idea on the timeline for implementing this?

Hi @Josh_Shupack - It looks like we added this validation back before we supported varargs in our “structured builders”, the interfaces you see in buttons and sync table settings. We now partially support varargs in those builders, so it may be that we can remove this check. I’m chatting with the engineering team to see.

That said, varargs don’t play nice with optional parameters, and so may not be a good fit for a sync table. Namely, since varargs apppear at the end of the parameter list, all optional parameters before them must be populated, since varargs are positional. I’m not sure what your use case is, but I’d look for alternatives to varargs even if we did support them in sync tables.

What kind of alternatives do you recommend?

We’re trying to make it easier to create a search field which needs to be submitted as an array of JSON objects. Something like: [{“key”:“value”},{“key2”:7}]

The UX isn’t great, but in most cases I recommend creating a helper function that takes in the inputs using varargs, and outputs a JSON string that you pass to a string parameter of the sync table. For example:

MakeQuery("owner", "Eric", "quantity", "10")

Would produce the JSON:

{ "owner": "Eric", "quantity": "10" }

You then pass this to a parameter of the sync table that parses the JSON string to get the values out.

1 Like

Hello and thank you for your answer @Eric_Koleda. Super helpful and transparent as always! I have a related question.
Would you recommend the same approach for an action to update an item ?
For example, for an action to update a product, the only required parameter would be the product id. If I add varargs parameters, any optional parameter before would be set as an empty string, correct ?
So a mistake by a user could be easily made, like setting the product description to an empty string instead of just not updating it when he just wanted to update the properties handled by the varargs parameters.
I could just code the action to not update when the string is empty, but then I would lose the ability to intentionally erase the description…
What would be the ideal coda way to correctly identify the user intention ?

Hi @Martin_Portevin - Yes, I recommend the same pattern for actions as well, for the reasons you listed. I think varargs only really work well when a formula has no optional parameters and you are confident it won’t need any in the future.

1 Like