One of 2 parameters required (not both)

Hi there :slight_smile:

I’m trying my hand at pack creation, with the help of Build your own pack in 3 easy steps ( to get started, and then fleshing out/tweaking the code as necessary (esp. as it’s been a minute since I used JavaScript, and I was more or less a beginner even then). Trying to keep it simple (not that that’s ever been my strong point :sweat_smile: ).

I’m using GitHub - akashrchandran/spotify-lyrics-api.

So I’m creating parameters (step 2 in the Build Your Own Pack doc), and so far I’ve not been able to find a way (if there is one?) to specify that one of two parameters is required, but not both.

The API says the following:

Parameter Default value Type Description
trackid None String The trackid from spotify.
url None String The url of the track from spotify.

You must specify either trackid or url, otherwise it will retuen error.

Here’s where I’ve looked so far:

(I suppose, theoretically, I could put them both as optional and make a note in the documentation. But…for the sake of error-proof programming, I’d rather not if it’s possible to avoid it :slightly_smiling_face: )

Are you trying to create a formula with an optional parameter?

Below is some sample code of a pack I’ve built that includes 1 required with the rest being optional. You might be able to piece yours together with this example!

I believe the order of parameters is also important. The required ones must go first in the list, then the optional ones.

  name: "CreateNewFolder",
  description: "Creates a new folder in pCloud.",
  isAction: true,
  parameters: [
    coda.makeParameter({ type: coda.ParameterType.String, name: "name", description: "The name of the folder." }),
    coda.makeParameter({ type: coda.ParameterType.String, name: "folderId", description: "The ID of the folder.", optional: true }),
    coda.makeParameter({ type: coda.ParameterType.String, name: "path", description: "The path to the folder (discouraged).", optional: true }),
  resultType: coda.ValueType.Object,
  schema: CreateNewFolderSchema,
  execute: async function ([name, folderid = "", path = ""], context) {
    const request: coda.FetchRequest = {
      method: 'GET',
      url: `${encodeURIComponent(name)}&folderid=${encodeURIComponent(folderid)}&path=${encodeURIComponent(path)}`,

    const response = await context.fetcher.fetch(request);

    if (response.status >= 200 && response.status < 300) {
      return response.body.metadata;
    } else {
      console.error('Error:', response);
      throw new Error(`Error creating folder: ${response.status}`);

Hi @Amy_Weatherford - High five for giving Pack building a try :raised_hands:t2:. Unfortunately the SDK doesn’t provide a way to say “one of these two parameters are required”. Any given parameter is either required or optional. There are a few options you an take though:

  1. Only accept a URL. Just because the API supports an ID doesn’t mean your Pack needs to as well. The URL seems more user-friendly of the two.
  2. Include two optional parameters, and validate them in your code. Early in the execute function, check that the user has entered one and only one of them, and throw a UserVisibleError if they haven’t. It’s easier to misuse the formula, but the error should make it clear what the problem was.
  3. Have one required parameter that accepts an ID or a URL. The Pack code determines if the input is a valid URL, and if not assumes it’s an ID.

My recommendation would be to go with either option #1 or #3. I used something similar to option #3 in my Packs Metadata Pack, and you can see the code here:

Thanks! That’s not quite what I was after, but I definitely appreciate the answer nonetheless! (The idea is a formula where either parameter A or parameter B, is required, but not both. It’s a bit odd, haha.)

1 Like

Thank you–this is great! I’ll probably end up going with #3–I was already leaning towards it, and having sample code to look at just about clinches it, haha. (I may default back to #1 if #3 decides to be difficult on me, but we’ll see :laughing:

This is a good case where text enbeddings in a Pack could be handy.

Imagine a Pack formula with one parameter and you are free to articulate that parameter using words or numbers of your choosing.

Embedding vectors would make it possible to determine similarity, thus classifying the type at run time.

Sadly I don’t think I’m an advanced enough programmer/math person to fully grasp what you’re saying, but I have some idea–more after looking it up. Assuming that I understand right–yes, that could be very handy!

1 Like

I can appreciate the tech jargon is daunting. Maybe this and this will help.

The simplicity of text embeddings is that given two pieces of text, we can know how similar they are even when we can’t predict what the texts will be. As such, it’s possible to code a system expecting terms like tortoise and hare, but users might use turtle and rabbit.

This gives us a new tool in the development of applications that can react correctly despite the terms users choose to guide the apps and formulas.

1 Like

Oh my gosh…I’m so sorry for the delay! I just found this draft sitting here–apparently I started it and forgot to finish it :woman_facepalming: :woman_facepalming: :woman_facepalming: :woman_facepalming:

Welllll… The links ask me to sign up for a 7-day free trial, and at the moment I don’t have time. But your lovely explanation, as well as one of the link headlines, has me thinking it’s maybe a bit like… Kind of a step removed from lookup tables in Power Query? Kind of like lookup tables + fuzzy matching combined maybe? I’ll have to look at those articles later haha. But this sounds super interesting and very useful! (Also, this is a total leap given I’ve not even fully understood the embedding concept yet… But is this how natural language processing works–a sort of dynamic text embedding?? Maybe??)

Thanks for this, and so sorry again…

1 Like