Implement Custom Rows

Overview

Custom Rows are a powerful way to provide “ready-to-go” content directly into the builder. Think products, blog articles, events, coupons. And don’t forget that Saved Rows your customers might have will be loaded as Custom Rows the next time they load the builder.

All this content is crucial to make the most out of the Beefree SDK experience, and that’s why you can add UI elements in your app’s interface to:

• jump right to a Custom Rows category, without the need for the user to go into the Rows tab, click on the dropdown and select the category;

• provide additional information on the available rows, either through a tooltip or by showing a Content dialog with all the information and the links to the rows.

With this feature, you will reduce the friction needed to discover and access the builder’s Custom Rows. To do so, you’ll use the loadRows event, which will trigger the Custom Rows content dialog.

How it works

Here’s an example of our Beefree product, which integrates Beefree SDK, taking advantage of this method to load custom rows from its UI.

The toolbar in the application contains explicit call-to-action text links to load footers, which correspond to different categories of Custom Rows in the application.

When users click on “Mailchimp Footers”, the Custom Rows Content Dialog is triggered, meaning that the builder opens a communication channel with your application. In this case, no additional UI will be displayed, as the host application provides the URL to the rows associated with that call-to-action. This way, the Rows tab will be immediately selected, with the “Mailchimp Footers” category already selected:

But what if you wanted users to select the email footers they need from a large catalog of pre-built content? In that scenario, you could have a more generic “Load footers” call-to-action in the toolbar.

Clicking on “Load Footers” will once again trigger the Custom Rows content dialog, but this time the application could provide a dialog window where users can browse or search through available footers, and get some additional context on them. Here is a visual example of how it might look like, but as with all content dialogs you have complete freedom on what to show:

When users click on MailChimp, the modal window fades off, the builder switches to the “Rows” tab, and the MailChimp Footers are shown, ready to be dragged into the message.

How to integrate it

You can trigger the Custom Rows content dialog via the loadRows instance event.

bee.loadRows()

Once the Content Dialog is triggered, you have two options, as explained in the How it works section:

• Interact with the end user, as described in our Content Dialog documentation, and eventually return a URL of custom rows.

• Immediately return the rows URL, without displaying the Content Dialog. This is useful if you have a menu and already know which rows to load based on the interaction by the end user with you application’s UI.

Extending Custom Rows with content dialog

Content Dialog allows you to build user interfaces that let your users locate & insert additional content (Custom Rows) while they are working on their message.

By letting you establish an interaction layer between the editor and your application (e.g., you show a modal window), it allows your users to locate/build/insert new rows, thus making the Rows tab in the editor dramatically more flexible and scalable.

Note that Content Dialog may be used to load other content types, as merge tags, special links, or display conditions. Learn more about the Content dialog.

To start using it, you need to add the contentDialog object to beeConfig, or add the externalContentURLs parameter if you already use this feature in your editor configuration.

Here is an example of the syntax that needs to be added to the editor configuration document (beeConfig):

contentDialog: {
    externalContentURLs: {
            label: 'Search products',
            handler: function(resolve, reject) {
                // Your function
        }
    }
}

Understanding the end-user experience

From the perspective of your users, this additional configuration adds a new item (using your text label) in the Rows drop-down.

Here is a visual example of how the “Search products” label will be shown, at the bottom of the Rows drop-down.

Initializing the dialog

When the user clicks on the new menu item (e.g., “Search products” in the example above), what you define in the handler (a function with a Promise-like signature) is triggered.

You can use this event to display a form where the user can search for new items to insert in the message. Here is a visual example:

You could also ask the user to enter parameters that will affect the very structure of the rows (JSON documents) that will be imported into the editor, affecting the way they will display:

You can also mix both forms in a 2-step pattern.

Returning items to the editor

When the selection is made, you must return to the resolve function a URL containing the result (row’s list).

The response must match the same format used to define the externalContentURLs in beeConfig:

{"name":"Results name","value":"Results URL"}

This response will:

1. Create a new drop-down choice with the provided name

2. Display the rows provided by the URL in the rows panel

Notice that in the rows list, names returned by the Content Dialog display as highlighted elements to give them further visibility over starting choices.

The Content Dialog can be used as many times as the user needs and, depending on the response, the behavior may change:

1. Returning the same name

This overwrites the existing results, keeping the same name in the drop-down. This behavior perfectly matches our example above, where the host application returns “Your search results” every time the content dialog is resolved.

2. Returning a new name

This creates a new drop-down choice, keeping the previous results as selectable elements. Previous results are available directly in the drop-down.

Here is a visual example:

Live example

In our example, we are using this event to display a search form and transfer the user selection to the editor as custom rows.

The form is part of the application, so we are using the same elements and styles that users of the application are used to.

Displaying Saved Rows

Rows can be saved directly in the editor using the Save Rows feature. These rows are returned to the host application as JSON objects that you can store based on your application logic.

These same rows can then be fed back into the editor by leveraging Custom Rows.

To do so, the host application must make them available in a reachable location specified through the externalContentURLs parameter.

The rows are displayed based on your rows configuration, so you can categorize them, creating multiple lists of rows to improve the user experience.

Rows Configuration

Here is an example of a rows configuration that displays saved items divided into usage categories:

rowsConfiguration: {
  emptyRows: true,
  defaultRows: true,
  selectedRowType: 'Headers', // Pre-selects the "Headers" row from the external content list
  externalContentURLs: [
    {
      name: "Headers",
      value: "https://URL-01"
    },
    {
      name: "Footers",
      value: "https://URL-02"
    },
    {
      name: "Product grids",
      value: "https://URL-03"
    },
    {
      name: "Main article",
      value: "https://URL-04"
    }
  ]
}

And here is another example where saved rows are organized based on the campaign type:

rowsConfiguration: {
  emptyRows: true,
  defaultRows: true,
  selectedRowType: 'Newsletter', // Pre-selects the "Newsletter" row from the external content list
  externalContentURLs: [
    {
      name: "Acquisition series",
      value: "https://URL-01"
    },
    {
      name: "Newsletter",
      value: "https://URL-02"
    },
    {
      name: "Transactional",
      value: "https://URL-03"
    },
    {
      name: "Post-Purchase Drip",
      value: "https://URL-04"
    }
  ]
}

The following is an example of the response schema when the editor calls one of the provided URLs:

[{
    [{
        metadata: {
            name: 'My first row'
        }
        columns: { ... }
            ...
        }, // The row that was previously saved
        ...
    }]
},
{
    [{
        metadata: {
            name: 'My second row'
        }
        columns: { ... }
            ...
        }, // The row that was previously saved
        ...
    }]
},{
    [{
        metadata: {
            name: 'My third row'
        }
        columns: { ... }
            ...
        }, // The row that was previously saved
        ...
    }]
}]

Loading External Rows with an Instance Method

With the introduction of Saved Rows Management, we’ve also introduced the ability to load external rows with an instance method. See here for more details.