HomeGuidesAPI Reference
Submit Documentation FeedbackJoin Developer CommunityOptimizely GitHubOptimizely NuGetLog In

Extending the front-end with blueprints in Spire

This topic 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.

Extension guidelines

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.

Did this page help you?