Skip to content

Conformance Examples 0.1.0 — Partials: soft-failures

unknown-dynamic-key-soft-fails-and-emits-nothing

A dynamic {{> (expr) }} key that resolves to an unknown key is a soft failure: it emits nothing and reports one UnresolvedReference event. The event is stamped at the root, so its partialStack is empty.

Template

[{{> (which) }}]

Context

{
    "which": "nope"
}

Partials

Output

[]

recursion-limit-soft-fails-and-stops

A self-recursive partial rendered past maxPartialDepth soft-fails once with a RecursionLimit event and stops descending; the output is the portion rendered before the ceiling was hit. The over-deep tag is a static symbol with no source location, so the event's partialStack is empty.

Template

{{> node }}

Context

{
    "name": "1",
    "child": {
        "name": "2",
        "child": {
            "name": "3",
            "child": {
                "name": "4"
            }
        }
    }
}

Partials

node:

{{ name }}{{#if child }}{{#with child }}{{> node }}{{/with}}{{/if}}

Output

12

multiple-soft-fails-are-matched-in-emission-order

When a render emits more than one soft-fail event, softFails must list them in emission order: a TypeMismatch inside 'mathPartial' is reported before the UnresolvedReference from the dynamic partial key that follows it in the template. A runner that matched softFails as an order-insensitive set (as render-fixture's expectedSoftFails does) would also accept this fixture with the two entries swapped; the partials suite does not allow that, since a soft-fail's position in the array is itself asserted.

Template

{{> mathPartial }}{{> (which) }}

Context

{
    "x": "not-a-number",
    "which": "nope"
}

Partials

mathPartial:

{{ x | abs }}

Output

null

Source fixture: partials/soft-failures.json