Upgrade to Coveo Hive framework: FAQ

This article covers some questions related to upgrading from the Legacy UI Framework to the Coveo Hive framework.

What am I gaining if I decide to upgrade?

Modularity

Instead of using a single component that strives to do everything, the search page is now split in many smaller pieces, each one representing a Coveo Hive component. Each component has a single responsibility and displays its specific options.

Therefore, you can move components around much more easily from the Experience Editor.

Easier Website Integration

In previous Coveo for Sitecore releases, the website styling was tightly coupled to the search component view. A developer had to duplicate the search components to create their own view, mostly because of styling needs.

Now that the search page is composed of smaller components, you can much more easily move them around from placeholder to placeholder. The Coveo Hive components rely on placeholder settings to determine which components can go where.

You can either use the default settings provided by Coveo or use your own to gain complete control over the component placement.

Reusability of Search-Enabled Components and Pages

In the past, the Coveo for Sitecore components were parameterized through Rendering Parameters. This approach had many drawbacks, such as the inability to merge individual field values. The Coveo Hive components rely solely on data source items to get their parameters.

Leveraging data sources brings many benefits:

  • It decouples the component settings from the component itself, making it easier to share a common set of parameter values between many components.

  • It merges field values through standard item inheritance. In other words, you can have a data source that only sets a field value and inherits values for all the other fields.

  • It supports local and shared data sources. When the data source item is defined as a child of the page, it’s considered a local data source. The other alternative is to store the data source item elsewhere in the content tree. It’s then considered a shared data source.

    Many components can reference the same data source item.

  • It supports Sitecore branches to create pre-configured search-driven pages.

Efficient HTML Caching

HTML caching is an important feature in Sitecore. It can make the difference between a site that feels fast and snappy and one that feels slow and heavy. On the other hand, enabling caching when it’s inefficient might not bring the expected performance gain and can use a lot of memory.

The Coveo Hive components are designed with HTML caching in mind. Most of the components are "cached by data source", which is ideal. To achieve this, the rendered HTML depends solely on the data source parameter values. With a given set of parameters, the HTML is always the same regardless of the current visitor, or the page it’s bound to.

There’s one special component that makes HTML caching work for the others: the context component. Its purpose is to render all the non-cacheable information for the other components. The context HTML markup can’t be cached because it varies on many contextual factors such as the current item, the visitor, etc. Once the page is served, all the cached components can then access the context on the client-side and do their work.

Tighter Integration With the Coveo JavaScript Search Framework

Most of the Coveo Hive components are genuine Coveo JavaScript Search Framework components.

The only difference is that Coveo Hive adds a layer, allowing you to visually edit the component properties through standard Sitecore user interfaces. Many components specific to Coveo for Sitecore were added as well. They’re also pure JavaScript Search components that could be used as standalone components, outside of Sitecore.

The Coveo JavaScript Search Framework dependencies can be loaded dynamically using a CDN (see Understanding How the Coveo JavaScript Files are Loaded (CDN)).

Note

For more details about the advantages of Coveo Hive over the Legacy framework, see Coveo Hive Versus Legacy UI and the Coveo Hive: What Is It? blog article.

Important

New features of the new framework won’t be ported to the legacy framework. Only critical bug fixes will be applied to the old framework.

What if I want to upgrade?

The Legacy components aren’t compatible with the new framework, so you need to start your search interface over.

It takes some work to create a search interface that looks like your older search interface, but you will end up with reusable and easier to maintain components.

Can I port my existing components?

It depends on your specific component.

Coveo Hive Framework still uses the Coveo JavaScript Search Framework. All customization done using the JavaScript Search Framework components will work as usual.

However, some concepts were removed from the Legacy Coveo for Sitecore JavaScript.

Here are some things that were removed.

jQuery

Coveo for Sitecore no longer bundles jQuery with the new UI.

You can still use jQuery, but the package doesn’t provide an initialization call like this anymore: $("#search").coveoForSitecore()

CoveoForSitecore.componentsOptions

This variable has been removed.

The whole library is now stateless and uses custom Coveo JavaScript Search Framework components to trigger custom events to share options between many components.

This allows having many search Interfaces that have no chances of interfering with each other.

Note

For more information on the new components, see Coveo Hive framework.

Model.ToCoveoFieldName

To support HTML caching, all code related to a custom context has been transferred to the CoveoForSitecoreContext component and is now all handled client-side instead.

To translate your fields, use the JavaScript method CoveoForSitecore.Context.fields.toCoveo("@yourfield"). The Coveo Search Resources must be included in the page.