--- title: Result templates slug: '413' canonical_url: https://docs.coveo.com/en/413/ collection: javascript-search-framework source_format: adoc --- # Result templates _Result templates_ determine the format of the individual [query](https://docs.coveo.com/en/231/) results in a [search interface](https://docs.coveo.com/en/2741/). They're embedded within a specific [result layout](https://docs.coveo.com/en/360/), and a given template can only apply when its parent layout is selected. When a query is successful, each result is rendered according to the first template whose [condition](#assigning-conditions-to-your-templates) is satisfied by that result. ## Using the prebuilt templates The [JavaScript Search Framework](https://docs.coveo.com/en/187/) includes several prebuilt result templates for common content types (for example, Salesforce, Jira, Khoros Community). You can use these templates in your search interface by including the `templates.js` script after the framework script: ```xml ``` ## Registering your own templates You can register custom result templates instead of using the prebuilt ones. To register a custom template for a given result layout, embed a `script` tag in that layout (that is, in the corresponding [`ResultList`](https://coveo.github.io/search-ui/components/resultlist.html) component). The `script` tag must have the `class="result-template"` attribute and a `type` attribute that specifies which [template engine](#choosing-a-template-engine) to use. Each custom template (With the possible exception of the [default template)(#defining-a-default-result-template).] that's registered within a given `ResultList` should also have a unique [condition](#assigning-conditions-to-your-templates). ```xml
``` ## Designing a template The JavaScript Search Framework supports two [template engines](#choosing-a-template-engine) along with built-in [styling classes](#result-template-styling-classes), [components](#result-template-components), and [helpers](#result-template-helpers), allowing you to conveniently design your own templates for the various [result layouts](https://docs.coveo.com/en/360/) that are available in a search interface. ### Choosing a template engine Result templates can use either the [HTML engine (recommended)](#using-the-html-engine-recommended) or the [Underscore engine](#using-the-underscore-engine). You specify the template engine in the template `script` tag (that is, `type="text/html"` or `type="text/underscore"`). > **Notes** > > * Avoid using both the HTML and Underscore engines in the same template. > When the two engines are used together, Underscore conditions are evaluated first, and HTML conditions are evaluated next. > This can result in complex behaviors that are difficult to debug. > * The HTML and Underscore engines both support JavaScript Search Framework [result template components](#result-template-components). > If your use case is fulfilled by a preexisting component, you should use it instead of implementing your own [custom component](https://docs.coveo.com/en/297/) or using inline JavaScript. #### Using the HTML engine (recommended) HTML result templates are entirely based on JavaScript Search Framework [result template components](#result-template-components). They can be executed inside environments with strict content security policies (for example, Salesforce with Lightning Locker enabled). ```xml ``` If needed, you can expand the capabilities of HTML templates by developing your own [custom components](https://docs.coveo.com/en/297/). #### Using the Underscore engine [Underscore](https://underscorejs.org/#template) result templates are extremely flexible because they can execute arbitrary JavaScript code. However, they may not be compatible with, or secure enough for, strict content security policies or setups (for example, Salesforce with Lightning Locker enabled). Moreover, Underscore templates can become hard to read and difficult to maintain. They can also result in longer rendering times. ```xml ``` Instead of using Underscore templates, consider using HTML templates and developing your own [custom components](https://docs.coveo.com/en/297/). > **Note** > > While reading the [Underscore](https://underscorejs.org/#template) template engine documentation, you may notice that you can modify the delimiters (`<% %>`) by changing the `_.templateSettings` object. > > However, changing these delimiters can cause issues with the JavaScript Search Framework, as they're used internally. > The JavaScript Search Framework offers alternative delimiters (`{% raw %}{{ }}{% endraw %}`), which work the same way as the default delimiters. > > This can also be useful when using the JavaScript Search Framework with certain other technologies, such as ASP.NET or JSP, which use the `<% %>` characters to let the server interpret expressions. ### Creating a list layout template This is the default layout for search results. When creating a custom result template, use the [standard styling classes](#result-template-styling-classes) to organize your template into a grid. Your template will include a number of [result template components](#result-template-components). The JavaScript Search Framework offers a variety of standard components, and you can also develop your own [custom components](https://docs.coveo.com/en/297/) if needed. ```xml
``` ### Creating a card layout template The JavaScript Search Framework offers two [card layout-specific components](#card-layout-specific-component-list) that you can only use in Card layout result templates: * [`CardActionBar`](#using-the-cardactionbar-component) * [`CardOverlay`](#using-the-cardoverlay-component) #### Using the `CardActionBar` component The [`CardActionBar`](https://coveo.github.io/search-ui/components/cardactionbar.html) component renders a bar at the bottom of a card. Its primary use is to display action buttons for the result in which it embeds itself. To add a `CardActionBar`, insert the component as the last element in a `coveo-result-frame` element. ```xml
``` The prebuilt Card templates all feature the `CardActionBar` component, which they usually populate with a [`Quickview`](https://coveo.github.io/search-ui/components/quickview.html) button and a [`CardOverlay`](https://coveo.github.io/search-ui/components/cardoverlay.html) component. #### Using the `CardOverlay` component The `CardOverlay` component should be used inside the `CardActionBar` component. It displays complementary information about a result. The `CardOverlay` component works by : . Finding all of its child DOM nodes. . Creating a hidden overlay containing these nodes. . Displaying a toggle button to show the overlay. ```xml
``` When the end user opens or closes the `CardOverlay` component, it triggers an `openCardOverlay` or `closeCardOverlay` event, which you can bind to any [handler](https://docs.coveo.com/en/417#attaching-event-handlers). This is useful if you only want to execute actions when the end user opens or closes the overlay. (For example, the [`ResultFolding`)(https://coveo.github.io/search-ui/components/resultfolding.html) component uses the `openCardOverlay` event to fetch additional results when the end user opens the overlay.] ### Creating a table layout template The JavaScript Search Framework allows you to customize the header and footer of your table using the `role` option. To specify a role, add a `data-role="table-header"` or `data-role="table-footer"` attribute to the `script` tag of your result template. ```xml
// Because this template has no `data-role` attribute, // it applies to each table row for your results. // You can also add a template // whose `data-role` is `table-footer`.
``` By default, table headers and footers behave as follows: * If you don't register any custom templates, the prebuilt Table template displays a table header with the default fields (that is, **Result Link**, **Excerpt**, and **Date**). * If you register a custom Table template but don't register a separate table header template, the table header is hidden. * By default, the table footer is hidden. * If you register a custom table footer template, the table footer is displayed. ## Assigning conditions to your templates Whenever a query result must be rendered, the JavaScript Search Framework uses its [condition evaluation mechanism](#about-the-condition-evaluation-mechanism) to determine which result template to use. Each template should have a unique condition that can only be satisfied by the desired subset of results. A condition can either be [field-based (recommended)](#using-field-based-conditions-recommended) or written in [JavaScript](#using-javascript-conditions). ### About the condition evaluation mechanism For each query result, the [custom result templates](#registering-your-own-templates) embedded inside the selected [result layout](https://docs.coveo.com/en/360/) (that is, in the selected `ResultList` component) are evaluated in the order in which they appear in the markup. The first template whose condition is satisfied by the result applies. If a result satisfies none of the custom template conditions, and if the [prebuilt result templates](#using-the-prebuilt-templates) are available, then the prebuilt templates are also evaluated until the query result satisfies a condition. ### Using field-based conditions (recommended) You can define a [field](https://docs.coveo.com/en/200/)-based condition by adding one or more `data-field-` attributes to the `script` tag of a custom result template, where you replace `` with the name of the field on which you want to base the condition clause (for example, `data-field-filetype`). ```xml
// If @filetype is "video": // Else if @filetype is "doc" OR @filetype is "pdf": // Else if @sfid contains any non-null value: // Else if @filetype is "html" AND @source is "mysource":
``` These conditions behave as follows: * In a single field-based clause with multiple values (for example, `data-field-filetype="doc,pdf"`), commas are interpreted as logical `OR` operators. * A field-based clause with no specified values (for example, `data-field-sfid`) is interpreted as a non-null check against the target field. * Distinct field-based clauses on the same template are joined with the `AND` logical operator. Field-based conditions can be executed inside environments with strict content security policies (for example, Salesforce with Lightning Locker enabled), and they're not likely to result in unrecoverable configuration errors. ### Using JavaScript conditions You can define a JavaScript condition by adding a `data-condition` attribute to the `script` tag of a custom result template. Most conditions rely on field values. These are accessible from the [`raw`](https://coveo.github.io/search-ui/interfaces/iqueryresult.html#raw) property of the current [query result](https://coveo.github.io/search-ui/interfaces/iqueryresult.html) (for example, `raw.filetype`). ```xml
// If @filetype is "image": // Else if @price is larger than 500:
``` JavaScript conditions are highly flexible, as they can evaluate arbitrary Boolean expressions. However, they may not be compatible with, or secure enough for, strict content security policies or setups (for example, Salesforce with Lightning Locker enabled). These conditions can also make it more difficult to detect faulty logic, as there's a greater margin for configuration errors. Moreover, it's possible to configure JavaScript conditions with invalid syntax, which would prevent results from rendering. ### Defining a default result template A result template with no condition will always apply if it's evaluated. You can use such a template as the default one for a given result layout by embedding it last within the desired `ResultList`. ```xml
``` > **Note** > > Since the JavaScript Search Framework evaluates custom templates before the prebuilt ones, including a custom template with no condition in a `ResultList` implies that the prebuilt templates will never apply for that layout. ## Reference ### Result template components You can use result template components to customize how your results are displayed in your search interface. > **Note** > > The generated [reference documentation](https://coveo.github.io/search-ui/globals.html) for all publicly exposed components is available on GitHub. To insert a component, add a `div` element with the `Coveo` class inside your template, where you replace `` with the name of the component that you want to insert (for example, `class="CoveoSort"`). Then define all of the required and/or desired options for that component by adding one or more `data-