Using Handlebar conditionals in REST Api raw-json body

[sdsys-ch]

Hey,

I'm aware that handlebar helpers (and by extension conditionals and the like?) can't be used in a raw json response of a REST API call.

Reference:

from here.

However, I can't seem to find a solution to my problem:

• API with multiple fields where
  • field_one and field_two always have to appear in the response together if at all
  • field_three can never appear next to either field_one or field_two (mutually exclusive)
• The bindings are set to empty (no value) for the query for default values.

Constructing the json seemed straightforward at first (simply not setting any of the mutually exclusive fields' values), however, the endpoint disagrees. If all three fields are in the payload, even if only one of the mutually exclusive groups has values, the endpoint complains. I've also tried setting those values to null without success.

So the solution seems to imply conditionally adding or removing fields based on given values, e.g.:

{

  {{#if Binding.field_one}}"field_one": "{{Binding.field_one}}",{{/if}}
  {{#if Binding.field_two}}"field_two": "{{Binding.field_two}}",{{/if}}
  {{#if Binding.field_three}}"field_three": "{{Binding.field_three}}",{{/if}}

  ...

  "other_field": "value"
}

and making sure the calling query only sets appropriate values (could keep logic for mutually exclusive groups inside json body as well with nested conditionals/ logical operators in a next step).

This however, doesn't work as per "Handlebars helpers can be used in automations, the design, and data table formula columns, but they cannot be used as part of data source queries" as long as conditionals are part of the helpers-category. I do have doubts here, since this doesn't include the conditionals, though it does {{ and }} and others that would come in handy and my tests haven't proven successful.

This makes the endpoint logic inside the REST datasource extremely flimsy (the actual API has one endpoint with four different, mutually exclusive "groups"), resulting in multiple queries for the same endpoint and additional logic inside the screens to choose the correct datasource query. I'd much rather ask the API providers to treat empty values as non-existent, but that's something that won't happen.

Short of creating multiple queries to the same endpoint with individual json bodies including the correct fields, what other options come to mind?

I'd really appreciate input on this.

Thanks!

[sdsys-ch]

Additional findings:

Apparently, the linked Bindings document also misses to note that handlebar helpers can't be used in some design components, e.g. the Markdown Viewer.

This does not work:

| Property | Value |
|-----------------|-----------------|
| Name | {{  Table By UID.get_by_uid.name }} |
| Legal Form | {{  Table By UID.get_by_uid.legalForm }} |
| UID | {{  Table By UID.get_by_uid.uid }} |
| State | {{  Table By UID.get_by_uid.state }} |
{{#isEmpty Table By UID.get_by_uid.deletionDate }}{{else}}| Deletion Date | {{ Table By UID.get_by_uid.deletionDate }} |{{/isEmpty}}
| Status | {{ Table By UID.get_by_uid.status }} |
...

The conditional #isEmpty statement brakes the field value.

It would be great if all of the handlebar helpers were supported wherever singular Handlebar statements are supported as it would reduce development time, not having to resort to JS in most cases.

I'm not sure what the constraints and workload would be here? I'd be willing to look into this with some pointers if time allows.

Thanks again.

edited: made clear which statement brakes the property.

[Sytten]

I am having the same problem, this is a big limitation since we cant even script the body creation...

EDIT: I managed to get over it by doing the handlerbar logic in the form submit instead