Any configuration option to have the parser leave uncaptured variables unchanged?

[hugoqribeiro]

I'm trying to find a way to configure the parser to leave such variables unmodified in the output...

Consider the following template:

Hello {{Name}}
Etc.

If we send a dictionary (as the model) only with the following value:

["Email"] = "XXX"

The output is:

Hello
Etc.

In our scenario, this error could go easily unnoticed, so we want to have the parser to leave {{Name}} unchanged...

Is it possible?

[drewburlingame]

We would find the same feature helpful in cases where we have a master template that can be partially rendered in one stage and then the remaining variables rendered in a following stage.

[sebastienros]

leave {{Name}} unchanged

{name} is a limited example, because it would be easy to provide a hook when a member is not defined to render warning, but how would you handle {name | uppercase}, or {% if name = 'eric' %}. So a direct substitution doesn't seem possible.

@drewburlingame looks like you want templates to generate templates, which technically is doable by rendering something that contains {name} and escaping the brackets.

[drewburlingame]

@sebastienros yeah that makes sense. Our situation is complicated by the fact that our customers are not aware of the different stages so they don't know which variables to escape.

In answer to your question about how to handle {name | uppercase}, we'd prefer the whole block to pass through. I can see how conditional statement will be more complicated to detect, especially if its checking for null. It would help if Fluid could distinguish between 'null' because key does not exist vs key exists and value null.

[sebastienros]

It would help if Fluid could distinguish between 'null' because key does not exist vs key exists and value null.

Correct. To be able to do that we need to change ValueTask<FluidValue> FluidValue.GetValueAsync(string name, TemplateContext context) to TryGetValueAsync to note that the member is not available (still return nil). The current nil value is no sufficient since it represents both null values and undefined ones. Or we'd need a custom undefined FluidValue inheriting from nil that would mean a member which doesn't exist. (Equivalent to false for TryGetValue).

Maybe something to do at the same time that the member accessors would be refactored to accept any property by default (not allow-listed by default like today).