Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Template unpacking logic (in JSON) is really shaky. It's easy to fall into a trap where it doesn't unpack because of YAML syntax (e.g. forgetting to trim whitespace before/after the chunk):
unpacked: "{{ 3 }}"
not_unpacked: >
{{ 3 }}
unpacked_again: >-
{{ 3 }}The behavior could be surprising, because the user writes a string but a change in whitescape could turn that string into a number or something else. If you want to opt out, you have to explicitly case to string with | string() which is wonky.
Describe the solution you'd like
A clear and concise description of what you want to happen
Unpacking should be explicit and opt-in. I'm thinking special syntax on a template chunk to indicate it should be unpacked:
packed: "{{ 3 }}"
unpacked: "{{~ 3 }}"Still undecided on the exact token, ~ is just the first thing that came to mind. If the token is given when an unpack isn't available, the template will fail to parse with a clear error:
unpack_error: "cannot be {{~ 'unpacked' }}"Something like Template expression cannot be unpacked because the template has more than one chunk.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered
- Leaving the current system. It works, but I listed the reasons I hate it above
- Tag entire templates instead of individual chunks, like this:
body:
type: json
data:
username: "{{username}}"
age: !expr "age"I like this solution because:
- It matches the underlying semantics better. The entire template is actually a single expression, so it's impossible to represent it invalidly (other than an expression being invalid syntax)
- You don't need the wrapping
{{ }}, which are useless because you know there won't be any other content
- I think it would be easier to implement underneath because the syntax matches the semantics more closely
Unfortunately this doesn't work because YAML tags are incompatible with JSON schema. There's no equivalent to tags in JSON, so there's no way to represent them in JSON schema. This is why I originally ditched YAML tags in v4.0.
Additional context
Add any other context or screenshots about the feature request here
This will be a breaking change, because all JSON templates would not be unpacked after migration. Could mitigate that by adding a warning when opening a v6 collection with templates that would've been unpacked in the past.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Template unpacking logic (in JSON) is really shaky. It's easy to fall into a trap where it doesn't unpack because of YAML syntax (e.g. forgetting to trim whitespace before/after the chunk):
The behavior could be surprising, because the user writes a string but a change in whitescape could turn that string into a number or something else. If you want to opt out, you have to explicitly case to string with
| string()which is wonky.Describe the solution you'd like
A clear and concise description of what you want to happen
Unpacking should be explicit and opt-in. I'm thinking special syntax on a template chunk to indicate it should be unpacked:
Still undecided on the exact token,
~is just the first thing that came to mind. If the token is given when an unpack isn't available, the template will fail to parse with a clear error:Something like
Template expression cannot be unpacked because the template has more than one chunk.Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered
I like this solution because:
{{ }}, which are useless because you know there won't be any other contentUnfortunately this doesn't work because YAML tags are incompatible with JSON schema. There's no equivalent to tags in JSON, so there's no way to represent them in JSON schema. This is why I originally ditched YAML tags in v4.0.
Additional context
Add any other context or screenshots about the feature request here
This will be a breaking change, because all JSON templates would not be unpacked after migration. Could mitigate that by adding a warning when opening a v6 collection with templates that would've been unpacked in the past.