> For the complete documentation index, see [llms.txt](https://docs.fact-finder.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fact-finder.com/webcomponents-overview/web-components-4.x./guides/essentials/template-engine.md).

# Template Engine

Bind FactFinder response data safely with Mustache templates.

All `{{data-bindings}}` used in FactFinder Web Components refer to the underlying JSON response returned by FactFinder.

You can take a look at all available bindings by opening your browser's **Dev Tools** (**press F12 key**) and navigating to the **Network** tab. Filtering by **XHR** makes things easier.

{% hint style="info" %}
For backward compatibility the response received from FactFinder NG is transformed into the pre-NG format. While it is mostly identical, you cannot reliably refer to the response reported by the browser to look up your data bindings.

Instead, inspect the actual data that arrives at the elements.
{% endhint %}

To inspect the incoming data, go to your browser's console and register a [topic listener](file:///api/4.x/core-result-dispatcher) at the `ResultDispatcher`. The most interesting topics here are probably `result` and `suggest`.

Next, trigger a search, for example through the search box or filters. The response data as delivered to the elements will be printed. From here, you can inspect it for the required data bindings.

Every element with a visual component is bound to one of these objects. For example, the `ff-record-list` element is bound to the `records` array and `ff-record` elements are bound to one array element each. The `ff-asn` element receives `groups`.

{% hint style="info" %}
The template engine HTML escapes the content of those data bindings. If you want the data to be interpreted as HTML, use triple curly braces like `{{{data-binding}}}`.
{% endhint %}

### Danger of Cross Site Scripting (XSS)

Be aware that any JavaScript included in your `{{{data-binding}}}` will be executed if put in triple curly braces.

This is potentially dangerous where values from the URL are inserted. An example is the [Breadcrumb Trail](file:///api/4.x/ff-breadcrumb-trail) with `{{{text}}}` for items of type `search`. Following a malicious URL could result in unwanted code running in the user's browser.

### Data Binding Example

By expanding the records array and one of its items, we can take a look at the fields returned by FactFinder. In this specific example, product data is stored in a record object. All fields returned in this object are imported during the data feed process. The fields to be returned can be configured in the FactFinder UI.

Consider the following data-binding example to see how to access the data.

```html
<ff-record-list>
    <ff-record>
        <div>Title: {{record.Title}}</div>
        <div>position: {{position}}</div>
    </ff-record>
</ff-record-list>
```

### Underlying Engine (mustache.js)

FactFinder Web Components uses **mustache.js** as the engine to resolve its HTML templates. Please refer to the official documentation for available features and their usage:

[https://github.com/janl/mustache.js/](https://github.com/janl/mustache.js/#mustachejs---logic-less-mustache-templates-with-javascript)

For example, you can render parts of your template conditionally by using [this syntax](https://github.com/janl/mustache.js/#false-values-or-empty-lists):

```html
<ff-record>
    <div>{{record.Title}}</div>
    {{#record.isOnSale}}
        <div>Special discount: {{record.Discount}}</div>
    {{/record.isOnSale}}
</ff-record>
```

In the example above, only when `record.isOnSale` holds a truthy value will the contained `div` with *"Special discount"* be rendered.

As **mustache.js** does not offer logic in templates, your data must adhere to a certain format in some situations. If the data to be displayed is not provided in the required format, use [ResultDispatcher.addCallback()](file:///api/4.x/core-result-dispatcher) to modify it accordingly.

### Clashes with Third Party Frameworks' Data Binding

Most front-end frameworks provide their own data binding syntax. As it stands, `{{ }}` seems to be the most popular choice for these data bindings.

This often leads to conflicts when you are embedding FactFinder Web Components in third party frameworks. Typically, your framework resolves all data bindings *before* the resulting HTML is accessible to Web Components.

{% hint style="info" %}
Make sure that your framework renders the Web Components HTML templates with intact data bindings.
{% endhint %}

To combat such conflicts, your framework might offer a way to render parts of your template verbatim.

An example with JSX syntax:

```jsx
return (
    <ff-template>
        <div>Regular binding: {'{{name}}'}</div>
        <div>HTML binding: {'{{{html}}}'}</div>
    </ff-template>
);
```

Another method that can provide a viable solution is to define custom delimiters to be used by Web Components' template engine. You can do so by setting the `mustache-delimiters` attribute on [ff-communication](file:///api/4.x/ff-communication#tab=api) accordingly. For example:

```html
<ff-communication
    mustache-delimiters="[[,]]"
></ff-communication>
```

This allows you to define your HTML templates like this:

```html
<ff-template>
    <div>Regular binding: [[name]]</div>
    <div>HTML binding: [[{html}]]</div>
</ff-template>
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.fact-finder.com/webcomponents-overview/web-components-4.x./guides/essentials/template-engine.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.