Upgrade to Coveo Hive framework: FAQ

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.

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.

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:

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.

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)).

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()

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.

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.