This repository contains the Library plugin for the Franklin Sidekick.
The Sidekick Library is an extension for the AEM Sidekick that enables developers to create UI-driven tooling for content authors. It includes a built-in blocks plugin that can display a list of all blocks to authors in an intuitive manner, removing the need for authors to remember or search for every variation of a block. Developers can also write their own plugins for the sidekick library.
The steps below detail how to setup the sidekick library and configure the blocks plugin.
The sidekick library is populated with your plugins and plugin content using a sheet.
- Start by creating a directory in sharepoint or gdrive where you want to store the content for the library. We recommmending storing the content in
/tools/sidekick(or any other name) in the root of the mountpoint. The next steps will assume the directory is called/tools/sidekick. - Next create a workbook (an Excel file) in the
/tools/sidekickdirectory calledlibrary(or any other name). Each sheet in the workbook represents a plugin that will be loaded by the Sidekick Library. The name of the sheet determines the name of the plugin that will be loaded. Any data contained in the sheet will be passed to the plugin when loaded. The plugin sheet name must be prepended withhelix-. For example, if you want to load a plugin calledtags, you would create a sheet namedhelix-tags. - For this tutorial we will create a sheet for our
blocksplugin. Create a sheet (or rename the default sheet) and call ithelix-blocksand leave it empty for now.
The Sidekick library comes with a blocks plugin.
library.blocks.plugin.mp4
To generate content for the blocks plugin, you need to prepare a separate Word document for each block you want to include.
- Create a directory inside the
/tools/sidekickdirectory where you will store all the block variations. For example, you could create a directory calledblocksinside/tools/sidekick. - For this example, let's assume we want to define all the variations of a block called
columns. First create a Word document calledcolumnsinside theblocksdirectory and provide examples of all the variations of thecolumnsblock. After each variation of the block add in a section delimiter. (Example). - Preview and publish the
columnsdocument. - Open the library workbook created in the last section, inside the
helix-blockssheet, create two columns namednameandpath. - Next we need to add a row for our
columnsblock. Add the name of the block in the first column and the url to the document that defines the block variations in the second column. For instance, if you want to add thecolumnsblock, you could create a row with the nameColumnsand the path/tools/sidekick/blocks/columns. In order for the library to work across enviroments (page, live, prod) you should not use an absolute url for the path column. - Preview and publish the
libraryworkbook.
Since the example blocks are being published you should use bulk metadata to exclude the content inside of
/tools/**from being indexed.
The blocks plugins supports a special type of block called library metadata which provides a way for developers to tell the blocks plugin some information about the block or how it should be rendered.
| Key Name | Value | Description | Required |
|---|---|---|---|
| name | Name of the block | Allows you to set a custom name for the block | false |
| description | A description of the block | Allows you to set a custom description for a block | false |
| type | The type of the block | This tells the blocks plugin how to group the content that makes up your block. Possible options are template or section (details below) |
false |
| include next sections | How many sections to include in the block item | Use if your block requires content from subsequence sections in order to render. Should be a number value that indicates how much subsequent sections to include. | false |
| searchtags | A comma seperated list of search terms | Allows you to define other terms that could be used when searching for this block in the blocks plugin | false |
| tableHeaderBackgroundColor | A hex color (ex #ff3300) | Overrides the table header background color for any blocks in the section or page. | false |
| tableHeaderForegroundColor | A hex color (ex #ffffff) | Overrides the table header foreground color for any blocks in the section or page. | false |
| contentEditable | A boolean value (default: true) | Set to false to disable content editing in the preview window. | false |
| disableCopy | A boolean value (default: false) | Set to true to disable the copy button in the preview window. | false |
| hideDetailsView | A boolean value (default: false) | Hide the block details panel inside the preview window. | false |
There are two types of library metadata. Library metadata that lives within a section containing the block, or default library metadata that applies to the document as a whole and lives in a section on it's own (a block called library metadata as the only child in a section).
Let's take an example of a hero block that has 5 variants. Suppose you want to add the same description for each variation of the block, rather than duplicating the library metadata with the description into each section containing the variations. You could instead use default library metadata to apply the same description to every variation of the block. If you decide that one variation actually needs a slightly different description you could add library metadata to the section containing the variation and it would override the default library metadata description when it's rendered within the blocks plugin.
By default the block name (with variation) will be used to render the item in the blocks plugin. For example, if the name of the block is columns (center, background) than that name will be used as the label when it’s rendered in the blocks plugin. This can be customized by creating a library metadata section within the same section as the block. Library metadata can also be used to author a description of the block as well as adding searchTags to include an alias for the block when using the search feature.
Example block with custom name and description
Content
Display
The blocks plugin is capable of rendering default content and autoblocks. In order to achieve this, it is necessary to place your default content or autoblock within a dedicated section, which should include a library metadata table defining a name property, as previously described. If no name is specified in the library metadata, the item will be labeled as "Unnamed Item."
There are situations where developers may want a block to consist of content from subsequent sections. This pattern is discouraged for reasons stated here, but if you choose to use it the blocks plugin can render these items using the include next sections property in library metadata.
Templates are a way to group an entire document into a single element in the sidekick library. To mark a document as a template set type to template in default library metadata.
Important, the
library metadataneeds to be in it's own section and be the only child to be considereddefault library metadata.
Supporting metadata is also desirable for templates. To add a metadata table to the template you can use a Page metadata block.
When the template is copied a metadata with the values will be added along with the content to the clipboard.
Since the sidekick library is hosted on the same origin as the content, a static HTML page needs to be created to load and configure the content.
-
Create a file called
library.htmlintools/sidekick/; -
Paste the following code in
library.html.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta
name="viewport"
content="width=device-width, initial-scale=1.0, viewport-fit=cover"
/>
<meta name="Description" content="AEM Sidekick Library" />
<meta name="robots" content="noindex" />
<base href="/" />
<style>
html,
body {
margin: 0;
padding: 0;
font-family: sans-serif;
background-color: #ededed;
height: 100%;
}
helix-sidekick { display: none }
</style>
<title>Sidekick Library</title>
</head>
<body>
<script
type="module"
src="https://www.aem.live/tools/sidekick/library/index.js"
></script>
<script>
const library = document.createElement('sidekick-library')
library.config = {
base: '/tools/sidekick/library.json',
}
document.body.prepend(library)
</script>
</body>
</html>In the code above we load the sidekick library from aem.live and then create a custom sidekick-library element and add it to the page. The sidekick-library element accepts a config object that is required to configure the sidekick library.
| Parameter Name | Value | Description | Required |
|---|---|---|---|
| base | Path to the library | The base library to be loaded | true |
| extends | Absolute URL to the extended library | A library to extend the base library with | |
| plugins | An object containing plugins to register with the sidekick library. | The plugins object can be used to register plugins and configure data that should be passed to the plugin | false |
The blocks plugin supports the following configuration properties that can be set using the plugins object.
| Parameter Name | Value | Description | Required |
|---|---|---|---|
| encodeImages | A boolean value that indicates if images should be encoded during copy operations | If your site has a Zero trust network access (ZTNA) service enabled such as Cloudflare Access then images should be encoded for copy/paste operations to work correctly with images. | false |
| viewPorts | Full or simplified configuration object, see examples below. | Configuration to overwrite the default viewport sizes. The default is 480px fo mobile, 768px for tablet and 100% of the current window for desktop. | false |
| contentEditable | A boolean value to disable content editing in all block previews. | Set to false to disable content editing. | false |
const library = document.createElement('sidekick-library')
library.config = {
base: '/tools/sidekick/library.json',
plugins: {
blocks: {
encodeImages: true,
}
}
}const library = document.createElement('sidekick-library')
library.config = {
base: '/tools/sidekick/library.json',
plugins: {
blocks: {
viewPorts: [600, 900],
}
}
}const library = document.createElement('sidekick-library')
library.config = {
base: '/tools/sidekick/library.json',
plugins: {
blocks: {
viewPorts: [
{
width: '599px',
label: 'Small',
icon: 'device-phone',
},
{
width: '899px',
label: 'Medium',
icon: 'device-tablet',
},
{
width: '100%',
label: 'Large',
icon: 'device-desktop',
default: true,
},
],
}
}
}You can customize the table header background and foreground color when pasting a block, section metadata or metadata that was copied from the blocks plugin.
Default styles can be set in library.html using css variables.
<style>
:root {
--sk-block-table-background-color: #03A;
--sk-block-table-foreground-color: #fff;
--sk-section-metadata-table-background-color: #f30;
--sk-section-metadata-table-foreground-color: #000;
--sk-metadata-table-background-color: #000;
--sk-metadata-table-foreground-color: #fff;
}
</style>These values can be overridden using library metadata.
Depending on the system color scheme selected for the users computer (dark mode), Word may alter the chosen colors in an attempt to improve accessibility.
The example below defines a tags plugin in the config. The keys of the plugins object must match the name of the plugin, any other properties defined in the plugin object will be available to the plugin via the context argument of the decorate method.
const library = document.createElement('sidekick-library')
library.config = {
base: '/tools/sidekick/library.json',
plugins: {
tags: {
src: '/tools/sidekick/plugins/tags/tags.js',
foo: 'bar'
}
}
}In some cases merging two block libraries may be desirable. When an extended library is defined the sidekick library application will merge the base library and the extended library together into a single library list for authors.
The example below defines a base library and an extended library (on another origin) that will be merged into the base library.
const library = document.createElement('sidekick-library')
library.config = {
base: '/tools/sidekick/library.json',
extends: 'https://main--repo--owner.hlx.live/tools/sidekick/library.json'
}The
Access-Control-Allow-Originheaders will need to be set on thelibrary.jsonand blocks of the extended library in order for them to load in the sidekick library. See Custom HTTP Response Headers for more info.
Due to same-origin policies enforced by browsers on iframes a preview of an extended block cannot be loaded at this time.
Next, in order for the sidekick library to appear in the sidekick a config file needs to be created at tools/sidekick/config.json. This config file needs to be created in the code bus and should be checked into github.
{
"project": "Example",
"plugins": [
{
"id": "library",
"title": "Library",
"environments": ["edit"],
"url": "/tools/sidekick/library.html",
"excludePaths": ["**"],
"includePaths": ["**.docx**", "/document/**"]
}
]
}The url property in the plugin configuration indicates the location from which the sidekick should load the plugin. This should point to the library.html file we previously created.
The sidekick config must be checked into the
mainbranch in order to for the plugin to appear in the sidekick.
If the
tools/sidekick/config.jsonfile does not exist in your github repository, it must be created. For more information on sidekick plugin configuration options, see the docs.
The sidekick library renders blocks by first fetching the plain.html rendition of the the block and then strips it of any other blocks in the content (for example if there are multiple variations of a block in the response). It then requests the same page (without .plain.html) and replaces the main element with the stripped block and loads the entire document into an iframe using the srcdoc attribute.
Since the block is loaded in an iframe using the srcdoc attribute, the instance of the window.location object used by your sites code will not contain the typical values you would expect to see.
Example window.location object when running in the library
{
"host": "",
"hostname": "",
"href": "about:srcdoc"
"origin": "null"
"pathname": "srcdoc"
"port": ""
"protocol": "about:"
}For this reason, if your block requires use of the window.location object we recommend adding the following functions to your scripts.js file and importing them into your function for use.
/**
* Returns the true origin of the current page in the browser.
* If the page is running in a iframe with srcdoc, the ancestor origin is returned.
* @returns {String} The true origin
*/
export function getOrigin() {
const { location } = window;
return location.href === 'about:srcdoc' ? window.parent.location.origin : location.origin;
}
/**
* Returns the true of the current page in the browser.mac
* If the page is running in a iframe with srcdoc,
* the ancestor origin + the path query param is returned.
* @returns {String} The href of the current page or the href of the block running in the library
*/
export function getHref() {
if (window.location.href !== 'about:srcdoc') return window.location.href;
const { location: parentLocation } = window.parent;
const urlParams = new URLSearchParams(parentLocation.search);
return `${parentLocation.origin}${urlParams.get('path')}`;
}The createOptimizedPicture function in lib-franklin also uses window.location.href. If you are using this function we recommend to move it into scripts.js and modify it to use the getHref() function above.
Sometimes you may want to know if the page or the block is running in the sidekick library. To do this there are a couple of options.
- Check if
window.location.href === 'about:srcdoc' - The
mainelement and the block element will contain thesidekick-libraryclass
Developing a plugin is similar to constructing a block in Franklin. Once a user tries to load the plugin, the sidekick library will trigger the decorate() method on your plugin. This method receives the container to render the plugin in and any data that included in the plugins sheet.
/**
* Called when a user tries to load the plugin
* @param {HTMLElement} container The container to render the plugin in
* @param {Object} data The data contained in the plugin sheet
* @param {String} query If search is active, the current search query
* @param {Object} context contains any properties set when the plugin was registered
*/
export async function decorate(container, data, query, context) {
// Render your plugin
}The
decorate()function must be exported from the plugin.
The default export from a plugin allows authors have the ability to customize the plugin name displayed in the header upon loading, as well as activate the search functionality within the sidekick library.
export default {
title: 'Tags',
searchEnabled: true,
};When the searchEnabled property is true, the library header will display a search icon upon loading the plugin. If the user initiates a search by entering a query, the decorate() function of the plugin will be triggered again, this time with the search string passed in the query parameter of the decorate() function.
Plugin authors can utilize a select set of web components from Spectrum when building a custom plugin.
The following components from Spectrum are available
| Component | Documentation Link |
|---|---|
| sp-tooltip | Docs |
| sp-toast | Docs |
| sp-textfield | Docs |
| sp-sidenav-item | Docs |
| sp-sidenav | Docs |
| sp-search | Docs |
| sp-progress-circle | Docs |
| sp-picker | Docs |
| sp-menu-item | Docs |
| sp-menu-group | Docs |
| sp-menu-divider | Docs |
| sp-menu | Docs |
| sp-illustrated-message | Docs |
| sp-divider | Docs |
| sp-card | Docs |
| sp-button-group | Docs |
| sp-button | Docs |
| sp-action-button | Docs |
| overlay-trigger | Docs |
The following icons from Spectrum are also available
| Component | Documentation Link |
|---|---|
| sp-icon-search | Docs |
| sp-icon-file-template | Docs |
| sp-icon-file-code | Docs |
| sp-icon-device-phone | Docs |
| sp-icon-device-tablet | Docs |
| sp-icon-device-desktop | Docs |
| sp-icon-magic-wand | Docs |
| sp-icon-copy | Docs |
| sp-icon-preview | Docs |
| sp-icon-info | Docs |
| sp-icon-view-detail | Docs |
| sp-icon-chevron-right | Docs |
| sp-icon-chevron-left | Docs |
Plugin authors can dispatch events from their plugin to the parent sidekick library in order to display a loader or to show a toast message.
import { PLUGIN_EVENTS } from 'https://www.aem.live/tools/sidekick/library/events/events.js';
export async function decorate(container, data, query) {
// Show a toast message
container.dispatchEvent(new CustomEvent(PLUGIN_EVENTS.TOAST, { detail: { message: 'Toast Shown!', variant: 'positive | negative' } }))
}import { PLUGIN_EVENTS } from 'https://www.aem.live/tools/sidekick/library/events/events.js';
export async function decorate(container, data, query) {
// Show loader
container.dispatchEvent(new CustomEvent(PLUGIN_EVENTS.SHOW_LOADER))
...
// Hide loader
container.dispatchEvent(new CustomEvent(PLUGIN_EVENTS.HIDE_LOADER))
}If testing a customer configuration locally that does not have the correct CORS headers set you will have to run the in a browser with web security disabled.
$ npm install$ npm run start$ npm test$ npm run lint$ npm run build