Optionally exclude form data field in query based on expression

[michaelyork]

Hi folks –

Is it possible to optionally exclude a form data field in a query based on a dynamic expression? This same pattern has worked for us in the past when sending up JSON, but seems to fail with form data.

For example, in this request, it looks like what should be evaluating to "expiration" is actually being sent up to the API as {{ 3 }} for some unknown reason:

[Pawel_Kapela]

Hi,
I have replicated your setting and haven't been able to it either in such a way.

The most straight-forward solution I see, is to:

1. Duplicate your original request and adjust its parameters
   

   

2. Make a JS query that selects the query based on desired properties (ex. filled field, a switch)
   

   

3. Now you can use and set interface triggers on that new switch query. It will behave like a normal query
   

   

This approach doesn't introduce much complication for the future development and keeps the logic deciding between those two or more queries in one place.

I have tried to include conditional fields to the query with JS, but didn't have much luck with that approach.

[bobthebear]

Option 1

instead of setting the key to be possibly null, you should set the value as possibly null. if your object has {"expiration": null} in it, then the field should be ignored, so you could try using:
key: expiration
value:

{{ add_document_expiration_date.value != null? add_document_expiration_date.value : null}}

or just

{{ add_document_expiration_date.value }}

because if it's null... then good, we don't want to change anything that way we end up with {"expiration": null}

Option 2

Just change the body type from Form Data to Raw and build your JSON object manually.

when you use Form Data the Content-Type header is automatically set to multipart/form-data. Likewise, when you use Raw it actually sets the header to multipart/form-data as well, so the only difference (that we care about here) is that Form Data gives you a GUI to use and Raw lets you manually build the JSON object that gets sent.

{
  'file': "data:" + {{ add_document_type.value }} + ";base64," + my_base64_string,
  "document_type": {{ add_document_type.value }},
  "note": {{ add_document_note.value }},
  {{ ...(add_document_expiration_date.value != null && {"expiration": add_document_expiration_date.value} }}
}

// the Logical AND (&&) 
//     - when expression is `False`
//         -returns the LHS (Left Hand Side.... whatever is to the left of &&)
//            - add_document_expiration_date.value
//     - when expression is `True`
//         -returns the RHS(Right Hand Side.... whatever is to the right of &&)
//            - {"expiration": add_document_expiration_date.value}

// next we use the Spread Operator (...) to copy the key/value pair for either the LHS or RHS that gets returned from above
//      - when copying RHS, we copy all the keys and values from `{"expiration": add_document_expiration.value}` into our object after the `"note"` property
//      - when copying LHS, the value is null and never an object, the spread operator won't do anything in this case so nothing is copied into our object

EDIT: some people might now be confused on the difference between these and JSON body type. with JSON you also get a GUI like Form Data only every field can only be of types text, number or object where as in Form Data you can specify lots more like file. The other difference is the Content-Type, with JSON you get application/json instead of multipart/form-data.... so the body contents are the exact same as Raw, but you're telling the server you're sending it application/json instead and when the server checks the Content-Type, which it does before looking at the body, and if it isn't supported then you, usually, get a 415 Error (instead of the server checking the body content then trying to figure out what it's suppose to be.... that isn't its job, its our job to tell the server what we send it so that we know it isn't misinterpreted). And Bob's your uncle .