Breadcrumb navigation

You can build a breadcrumb navigation with a breadcrumbItem schema that you reference from your page schemas. See more about referencing schemas. Each breadcrumb item references the breadcrumb item of its parent. The references chain up the tree until they reach a source entity without an originParentId.

/** @type {Enterspeed.FullSchema} */
export default {
  triggers: function(context) {
    context.triggers("cms", ["homePage", "contentPage"]);
  },
  properties: function (sourceEntity, context) {
    return {
      link: {
        name: sourceEntity.properties.metaData.name,
        url: sourceEntity.url,
        originId: sourceEntity.originId,
      },
      parent: sourceEntity.originParentId
                ? context.reference("breadcrumbItem").byOriginId(sourceEntity.originParentId)
                : null
    };
  }
}

Add every page type that can be a parent to the breadcrumbItem triggers. If a parent’s type is missing, its reference resolves to null and the breadcrumb is cut off at that page.For example, take the path homePage > sectionPage > contentPage > contentPage, where sectionPage isn’t in the triggers. The breadcrumb of the deepest contentPage stops below the sectionPage, so it only contains its parent contentPage. A contentPage directly below the sectionPage gets no breadcrumb at all. The only trace is in meta.missingViewReferences in the Delivery API response.

In your page schema, you only reference the breadcrumbItem view of the parent.

/** @type {Enterspeed.FullSchema} */
export default {
  triggers: function(context) {
    context.triggers("cms", ["contentPage"]);
  },
  routes: function(sourceEntity, context) {
    context.url(sourceEntity.url);
  },
  properties: function (sourceEntity, context) {
    return {
      breadcrumb: sourceEntity.originParentId
                    ? context.reference("breadcrumbItem").byOriginId(sourceEntity.originParentId)
                    : null
    };
  }
}

All references are by origin id, and Enterspeed resolves them at delivery time. This means you don’t need to reprocess the page views when you rename or move an ancestor. Every page below it gets the updated breadcrumb on the next request.

Use this approach even if your source entities have an array of all their ancestor ids. If you reference the ancestors by that array, moving a page changes the ancestor ids of all the pages below it. You then need to re-ingest all those pages to update their breadcrumbs.

The response contains the breadcrumb as a nested structure, from the parent of the current page up to the root.

{
  "route": {
    "breadcrumb": {
      "link": {
        "name": "Blog",
        "url": "https://example.com/blog/",
        "originId": "1100"
      },
      "parent": {
        "link": {
          "name": "Home",
          "url": "https://example.com/",
          "originId": "1000"
        },
        "parent": null
      }
    }
  }
}

In your frontend, you flatten the nested structure into a list of links, ordered from the root to the parent.

function flattenBreadcrumb(breadcrumb) {
  const links = [];

  for (let item = breadcrumb; item; item = item.parent) {
    links.unshift(item.link);
  }

  return links;
}

For the response above, flattenBreadcrumb returns the following list.

[
  {
    "name": "Home",
    "url": "https://example.com/",
    "originId": "1000"
  },
  {
    "name": "Blog",
    "url": "https://example.com/blog/",
    "originId": "1100"
  }
]

Overview

Schema reference

API

Integrations

Tutorials

Best practices

CLI

MCP server