Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Extend the front-end with blueprints in Spire

Describes how to extend the front-end with blueprints in Spire.

The goals of Spire are to ensure front-end upgradability while maintaining backwards compatibility on the public surface area of Spire for site extensions.

Locally, you will be working with the full Spire source code. When you build and deploy your Blueprint, Optimizely ignores any changes you make to the core Spire code, which you should only change to assist with troubleshooting issues. This includes everything exported directly or indirectly, except for \modules\shell and UNSAFE_ code.

Keep these guidelines in mind when extending Spire:

  • Optimizely uses a plug-in called goodfences to enforce the restriction not to reference the shell code.
  • There are some areas of code currently prefixed with UNSAFE_, which Optimizely will change in the near future, that you should not import directly. There are functions to get at the UNSAFE_ data in a safe manner for areas we plan on maintaining compatibility for, for example:
    • The Redux state includes state.UNSAFE_currentPage.page, which you can use to get the current page object. Referencing it this way in mapStateToProps causes issues, so Optimizely added a function getCurrentPage to \client-framework\Store\Data\Pages\PageSelectors.ts, which is the backwards compatible way of getting the current page object.
  • We do not currently support modifying package.json to import
    additional third-party libraries.
  • If a blueprint has a widget or page replacing a base code widget or page, you must include it in the overrides folder; if it is left out, then an error will occur.