M365 Development · SharePoint

Easily edit PnP Modern Search web parts properties

The PnP Modern Search solution contains multiple SharePoint Online modern web parts. Each of these web part is highly flexible and customizable. It means that each web part and more specifically the Search Results web part has many properties that you can set.

If you want to use PnP Modern Search web parts on many pages, it can be time consuming to set every time the same properties.

This blog post introduces two methods that will help you speed up PnP Modern Search web part configurations.

Content

  1. Using the property pane
  2. Using PowerShell
    1. Prerequisites
    2. Get current properties
    3. Edit properties
    4. Update web part
  3. Conclusion
  4. References

Using the property pane

The first option that you have to quickly edit properties of a PnP Modern Search web part can be found directly on the web part’s property pane (page 4).

Clicking on the Edit properties button will open up a new pane with raw web part properties in edit mode.

There you can directly edit properties from the embedded code editor. You can also Export properties (as a JSON file), edit it in your favorite code editor and finally Import the JSON file with updated properties.

As an example, let’s try to hide the results count of the Search Results web part:

By default, the the PnP – Search Results web part displays results count => showResultsCount property is set to true.

Now if you change the showResultsCount to false, the results count will be hidden:

Using PowerShell

Now if you have to edit a lot of pages you can automate things using PowerShell and more specifically the PnP PowerShell module.

Prerequisites

In this section we are going to use the PnP PowerShell module. If you haven’t already used it, please follow instructions there: Installing PnP PowerShell.

Get current properties

First, you need current web part properties. Let’s use the Get-PnPPageComponent cmdlet to retrieve current web part properties as an object:

$pageName = "Search"
$wpInstanceId = "4f78965f-3c5f-485f-9099-e0c98f1c6edd"
$currentSearchProperties = (Get-PnPPageComponent -Page $pageName -InstanceId $wpInstanceId).PropertiesJson | ConvertFrom-Json

You can easily find the instance Id of a PnP Modern Search web part using its property pane:

Edit properties

Now you can edit web part properties.

As an example let’s edit the query template property in order to get only News posts in the Site Pages library:

$currentSearchProperties.dataSourceProperties.queryTemplate = 'Path:"https://{tenant}.sharepoint.com/sites/organization-portal/SitePages" AND ContentType:"Site Page" AND PromotedState:2'

Update web part

Once you have edited the properties, you can update the web part using the Set-PnPPageWebPart cmdlet:

$pageName = "Search"
$wpInstanceId = "4f78965f-3c5f-485f-9099-e0c98f1c6edd"
Set-PnPPageWebPart -Page $pageName -Identity $wpInstanceId -PropertiesJson ($currentSearchProperties|ConvertTo-Json -Depth 3)

What is important here is to convert the $currentSearchProperties to JSON so it can be accepted by the cmdlet.

Conclusion

In this blog post we covered how to quickly edit PnP Modern Search web parts properties using either the web part property pane or the PnP PowerShell module.

References

SharePoint · Viva Connections

Viva Connections Card Designer – Advance API features (part 2)

This blog post is the second part of Viva Connections Card Designer – Advance API features (part 1).

It will focus on using the Microsoft Graph API and the Card Designer advance API features to display dynamic data within a Viva Connections dashboard card without code.

Content

  1. Prerequisites
    1. SharePoint Online Client Extensibility Web Application Principal
    2. Add required permissions
  2. Get data using Microsoft Graph API
  3. Display data
  4. Conclusion
  5. References

Prerequisites

The same prerequisites described in the part 1 should be met. In addition, the use of the Microsoft Graph API requires the following prerequisites.

SharePoint Online Client Extensibility Web Application Principal

On the Card Designer card settings, if you try to execute a Graph API request (using the “Test” button), you will have the following error message: Cannot make any requests to Microsoft Graph as the SharePoint Online Client Extensibility Web Application Principal is not configured or consented to.

It means that the SharePoint Online Client Extensibility Web Application Principal might not be created. This app is used to manage permissions that your Graph API requests require. This app is also the one managing permissions for SPFx solutions.

To check if this app has already been created, you can go to the Microsoft Entra admin center and check the “App registration” list:

To create this app, access the “API access” page from your tenant’s SharePoint admin center. :

If you check again the “App registration” page, the app is listed:

Add required permissions

Now that the SharePoint Online Client Extensibility Web Application Principal is created, we need to add permissions that are required for the API call we want to perform from the Card Designer.

In our example we want to get current user’s direct reports. So we will need at least the User.Read and User.ReadBasic.All permissions:

  1. On the SharePoint Online Client Extensibility Web Application Principal page, click on “API permissions”
  2. Click on “Add a permission”
  3. Select “Microsoft Graph” then “Delegated permissions”
  4. Select the “User.Read” and “User.ReadBasic.All” permissions then click on “Add permissions”

Finally, as an admin you must grant consent for the newly added permissions:

Get data using Microsoft Graph API

Once all the prerequisites are met, you can start using the Microsoft Graph API to get data from the Card Designer.

First, add a new Card Designer card to the Viva Connections Dashboard and select Call a Microsoft Graph API in the Data source dropdown:

Then you can write your request URL in the input field that appeared below. As an example, we want to get current user’s direct reports: v1.0/me/directReports

You can click on “Test” to preview the response of the request.

Display data

To display the data that you get using the API call in the quick view of the card, use an adaptive card JSON template. To display current user’s direct reports, you can you the template below:

{
  "type": "AdaptiveCard",
  "body": [
    {
      "type": "Container",
      "$data": "${value}",
      "style": "default",
      "bleed": true,
      "items": [
        {
          "type": "TextBlock",
          "text": "${displayName}",
          "wrap": true,
          "weight": "Bolder",
          "size": "Medium"
        },
        {
          "type": "TextBlock",
          "text": "Email: ${userPrincipalName}",
          "isSubtle": true,
          "wrap": true,
          "spacing": "Small",
          "maxLines": 2
        }
      ]
    }
  ],
  "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
  "version": "1.2"
}

Click on “Apply”, then “Republish” and you can now access dynamic data from the quick view of your Card Designer card:

Conclusion

In this blog post, we covered how to use Viva Connections Card Designer advance API features to get data using Microsoft Graph API and display retrieved data on the card quick view.

References

SharePoint · Viva Connections

Viva Connections Card Designer – Advance API features (part 1)

The Card Designer is a type of card that you can add to your Viva Connection dashboard. You could customize the design of this card using Adaptive Cards templating and choose predefined actions for the card primary and secondary buttons (e.g.: show the quick view, go to a link).

In December 2023, Microsoft introduced a set new advance API features that enable the use of API to get specific data without code and then display it in the quick view using templates.

This blog post demonstrates, using these new features, how to get specific data using the SharePoint API.

Content

  1. Prerequisites
    1. Enable features
    2. Create the tenant App catalog
  2. Get data using SharePoint API
  3. Display data
  4. Conclusion
  5. References

Prerequisites

This section describes the prerequisites to use the advance API features to get data with the SharePoint API.

You will need SharePoint admin permissions to perform the actions described below.

Enable features

If you add a new Card Designer card to you Viva Connections dashboard, you will notice the following warning message in the “Quick view layout and data section”:

To use the new advance API features of the Card Designer, you have to enable it. To do so, use the SharePoint Online PowerShell. Make sure you have the latest version installed and execute the following cmdlets:

Connect-SPOService -Url "https://yourtenant-admin.sharepoint.com/"
Set-SPOTenant -IsDataAccessInCardDesignerEnabled $true

You can now execute Get-SPOTenant to make sure that the property is successfully enabled:

Create the tenant App catalog

Now, if you access a Card Designer card settings and see the following warning message, it means that your tenant does not already have a tenant App catalog:

If your tenant does not already have an App catalog, you will have to create it. To do so, access the SharePoint admin center and then go to “More features” and click on “Open” in the “Apps” section. It will automatically create the app catalog:

Get data using SharePoint API

Once all the prerequisites are met, you can start using the new advance API features of the Card Designer.

Let’s see how to get data using the SharePoint REST API:

First, add a new Card Designer card to the Viva Connections Dashboard and select Call a SharePoint API in the Data source dropdown:

Then you can write your request URL in the input field that appeared below. As an example, we want to get files of the Documents library: /GetFolderByServerRelativeUrl('Shared%20Documents')/Files

You can click on “Test” to preview the response of the request.

Display data

To display the data that you get using the API call in the quick view of the card, use an adaptive card JSON template. To display the files from the Documents library, you can you the template below:

{
  "type": "AdaptiveCard",
  "body": [
    {
      "type": "Container",
      "$data": "${value}",
      "style": "default",
      "bleed": true,
      "items": [
        {
          "type": "TextBlock",
          "text": "${Name}",
          "wrap": true,
          "weight": "Bolder",
          "size": "Medium"
        },
        {
          "type": "TextBlock",
          "text": "Last modified on {{DATE(${TimeLastModified}, COMPACT)}}",
          "isSubtle": true,
          "wrap": true,
          "spacing": "Small",
          "maxLines": 2
        }
      ]
    }
  ],
  "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
  "version": "1.2"
}

Click on “Apply”, then “Republish” and you can now access dynamic data from the quick view of your Card Designer card:

Conclusion

In this blog post, we covered how to use Viva Connections Card Designer advance API features to get data using SharePoint API and display retrieved data on the card quick view.

In the next part, we will see how to do the same using the Microsoft Graph API.

References

M365 Development · SharePoint · Viva Connections

How to use text input in Adaptive Card Extensions’ card views

To use an input field on an Adaptive Card Extension (ACE), you could only do it on a quick view of the card. Since SPFx v1.18, it is possible to use a text input component directly on an Adaptive Card Extension’s card views.

For instance, if your adaptive card main purpose is to get a simple input from users, you could really benefit from this new feature.

This blog post demonstrates how to implement this feature.

Content

  1. Requirements
    1. New adaptive card
    2. Existing adaptive card
  2. Use the new default class for card views
  3. From the card footer
  4. From the card body
  5. References

Requirements

New adaptive card

If you want to implement the feature on a new adaptive card extension, perform the following steps:

  1. Make sur you have the latest version of the SharePoint Framework installed : npm install @microsoft/generator-sharepoint@latest --global
  2. Run yo @microsoft/sharepoint
  3. Select Generic Card Template in the generator

Existing adaptive card

You can also implement this feature on an already existing ACE created with an on older SPFx version. To do so, you need to migrate your Adaptive Card Extension to SharePoint Framework v1.18.

Since SPFx v1.18 new classes and other architectural changes, migration to this version requires additional steps. You can find more details here: Migrate Adaptive Card Extensions to SharePoint Framework v1.18

Use the new default class for card views

SPFx v1.18 introduce BaseComponentsCardView as the new default class for Adaptive Card Extensions card views. You can use this new class to specify components that you want to display in a card view:

The first option that you have, is to use a text input component in the footer of your card view.

In the BaseComponentsCardView class, define the BasicCardView as follows:

As you can see, the componentName property of the footer is defined as textInput. You also have the following properties:

PropertyDescription
idId of the component
placeholderPlaceholder of the text input component
button/iconDefine the icon of the button
button/actionAction to perform when the button is clicked

From the card body

The second option is to use an text input component in the body of your card view.

In the BaseComponentsCardView class, define the TextInputCardView as follows:

Here the textInput component is defined in the body. You can set the following properties:

PropertyDescription
idId of the component
placeholderPlaceholder of the text input component
iconBeforeDefine the icon on the left-hand side of the input component.

Note that in this case the button is still defined on the footer part of the Adaptive Card Extension.

References

Power Automate · SharePoint

How to create a list item with a person field using Power Automate

The objective of this blog post is to show multiple ways to create a new SharePoint list item with a person field using a Power Automate flow.

Content

  1. Create item action
    1. Static number of users
    2. List of users defined in a variable
  2. Send an HTTP request to SharePoint
    1. Retrieving user id
  3. References

Create item action

First, let’s use the “Create item action”:

Static number of users

If you have a static number of users to enter in the person field, you can fill each “Claims” field with the email address of a specific user.

You can add more users using the “Add new item” button.

List of users defined in a variable

Now let’s say that the number of users you want to add to your person field depends on the logic of your flow (e.g.: specific conditions, variables).
To do so, you need to have an input with the following format:

[
  {
    "Claims": "BiancaP@M365.OnMicrosoft.com"
  },
  {
    "Claims": "BrianJ@M365.OnMicrosoft.com"
  }
]

To get that specific format, you can use array variables:

Send an HTTP request to SharePoint

But in some cases, the Create item action might not match your requirements (e.g.: use the same flow for multiple sites). So you need to use the Send an HTTP request to SharePoint action.

Retrieving user id

With the Send an HTTP request to SharePoint action, you need to use the user id from the User Information List for each user you want to add in your person field.

The idea would be to use other HTTP requests to get all users ids and then use those ids to fill the the person field:

But not every users are in the User Information list of every SharePoint sites. For example, if a user never got access to a specific site, the user won’t be listed in the User Information list. Hence you won’t be able to retrieve the user id using the action above.

What you can do instead is use the ensure user endpoint of the SharePoint REST API:

With this action, you both create the user in the User Information list and you retrieve its id that you will be able to use to fill the person field using the syntax below (for a multiple selections field):

"InternalColumnNameId": {"results":[15]}

You can add multiple users by adding multiple ids in the “results” array.

If the person field does not allow multiple selections, use the following syntax:

"InternalColumnNameId": 15
Fill the “People” field using user Id from Ensure user action

References

SharePoint

Edit SharePoint site search verticals

On a SharePoint site, site admins can customize search verticals that are used when searching on the site.

In this blog post we are going to see what type of customizations site admins can do and how to do it.

Content

  1. What are search verticals
  2. Edit a default search vertical
    1. Name
    2. Query
      1. Standard query
      2. Use profile query variables
      3. Use query string variables
    3. Filters
  3. Create a new vertical
  4. Conclusion
  5. References

What are search verticals

Search verticals are tabs on the search result page that show results of a specific type or from selected sources. For example, the Files vertical only shows files matching the search query (it won’t show list items for example).

Site level search verticals are only used when searching within a specific site scope.

Site level search verticals are not used when search on the Organization scope.

Edit a default search vertical

By default, each site has the following 5 search verticals:

  • All
  • Files
  • Sites
  • News
  • Images

To access and open the edit pane of a default site level search vertical, perform the following steps:

  1. Access the site settings page: “your site url”/_layouts/15/settings.aspx
  2. Click on “Search insights and configuration” in the Microsoft Search category
  3. Click on the “Verticals” tab
  1. Double click on the vertical you want to edit
  2. Click on the “Edit” button

Name

First, let’s edit the Name of a vertical (we will use the ‘News’ vertical as example).

To do so:

  1. Click on the “Edit” link below the name. Then select “Create a custom name”:
  1. Click on “Review” and “Update vertical” and finally “Done”:

Query

Standard query

A query rule can be added (using KQL) to limit the scope of a vertical.

Let’s define a simple query rule for a vertical.

Let’s say that we want the “Department News” vertical to show only news with a specific title.

To do so:

  1. Click on “Edit” below the “Rules” menu:
  1. Add your KQL query in the dedicated text box:
  1. Save your modification just like you did for the title modification.

In this example the “Department News” vertical will only show news with a name starting by “Welcome”.

Use profile query variables

Profile query variables can be used to contextualized search results to the signed-in user.

In our example, we want the “Department News” vertical to show only news modified by the signed-in user.

To do so:

  1. Add the following KQL query to the dedicated text box: ModifiedBy:{Profile.names.displayName}:

You can find the profile resources that you can use here: profile resource type.

Use query string variables

Query string variables allow you to customize search results by adding key-value pairs to the search URL.

In our example, we want want to show news only with a specific Topic Header.

To do so:

  1. Add the following KQL query to the dedicated text box: RefinableString00:{QueryString.topic}

Notice that we had to map the TopicHeader property to a managed property to use it in the query rule.

  1. Use the following search URL: https://sampletenant.sharepoint.com/sites/Demosite/_layouts/15/search.aspx/sitenews?topic=“New joiner”&q=welcome

Filters

Filters can be used to refine results of a search query.

Some filters are available by default:

Let’s add a custom filter to the “Department News” vertical.

  1. Click on “Edit” below the “Filters” menu:
  1. Click on “Add a filter”:
  1. You can select the property to use for the filter. In our example, let’s select the managed property we used on the previous chapter and click on “Next”:

In our example, we have selected a Text property but you can also create DateTime filters.

  1. Define a name and choose if you want users to select single or multiple values and click on “Add”:
  1. Do not forget to validate the new filter by clicking on “Update vertical”.

Create a new vertical

All the modification that we made on the “News” vertical can be made on a fully custom vertical. You can just click on “Add” in the vertical menu to create a new vertical:

Once you have completed the configurations, do not forget to enable your vertical:

Conclusion

In this blog post we have seen the configurations that it is possible to make on site-level search verticals.

As you will see, any modification you make on verticals can take several minutes to show up on the search page (more than one hour sometimes in my experience). So here is a little tip for you: append cacheclear=true at the end of your search URL. With that, changes made on a vertical can be visible in a few minutes!

References

M365 Development

Mock responses with the Microsoft Graph Developer Proxy

The Microsoft Graph Developer Proxy is a tool that can help you test applications which use Microsoft Graph and other APIs. You can use this tool to perform the following tests:

  • Mocking responses
  • Simulating errors
  • Simulating throttling

In this blog post, we are going to see an example on how to use the Microsoft Graph Developer Proxy to mock API call responses without any code modification.

If you want more details about the Microsoft Graph Developer Proxy, you can go here: msgraph-developer-proxy.

Content

  1. Getting started
  2. Why mocking responses ?
  3. Responses configuration
  4. Start the proxy and test the application
  5. Summary
  6. References

Getting started

For this example, we will use:

  • A Microsoft 365 demo tenant – you can get one by signing up to the Microsoft 365 Developer Program
  • The Microsoft Graph Developer Proxy (obviously ;)) – you can install it by following the steps described here: Get started
  • An application using the Microsoft Graph API – in this example, we will use a Viva Connection Adaptive Card Extension that you can find here: ImageCard-MostLikedPages

Why mocking responses ?

In our case, the application displays most liked pages out of a list of selected SharePoint sites using the Microsoft Graph API.

To test this adaptive card extension, as a developer, you need to create multiple pages across different sites and to log on as different users to like those pages. This can take a lot of time, especially if you want to test different scenarios (e.g.: hundred of pages with multiple likes each).

Of course you could create your own file containing sample data instead of your real API call response. But then you would have to make some changes in your code, so this is not an ideal solution.

The great benefit of using the Microsoft Graph Developer Proxy is that you can mock responses without making any changes to your code !

Responses configuration

To configure the responses to mock, we need to create a responses.json. The great thing with the Microsoft Graph Developer Proxy is that each application can have its own responses.json file.

In our example, let’s create this file at the root of our ACE solution:

{
  "responses": [
    {
      "url": "", // URL of our API endpoint
      "method": "", // Method of our API call
      "responseBody": {}, // Body to send as the response to the request
      "responseHeaders": {} // Headers to include in the response
    }
  ]
}

We now want to mock a response to the following API call: https://graph.microsoft.com/beta/sites/{site-id}/pages?$select=reactions,title,webUrl,thumbnailWebUrl to get all pages of a specific site, along with their respective numbers of likes.

Our file will look like this:

{
  "responses": [
    {
      "url": "https://graph.microsoft.com/beta/sites/{site-id}/pages*",
      "method":  "GET",
      "responseBody": {
        "@odata.context": "https://graph.microsoft.com/beta/$metadata#sites('{site-id}')/pages(reactions,title,webUrl,thumbnailWebUrl)",
        "value": [{
        "webUrl": "SitePages/Page-1.aspx",
        "title": "Microsoft Graph Developer Proxy",
        "thumbnailWebUrl": "",
        "reactions": {
            "likeCount": 42
        }
    },
    {
        "webUrl": "SitePages/Page-2.aspx",
        "title": "About blueberries",
        "thumbnailWebUrl": "",
        "reactions": {
            "likeCount": 33
        }
    },
    {
        "webUrl": "SitePages/Home.aspx",
        "title": "Home",
        "thumbnailWebUrl": "",
        "reactions": {}
    },
    {
        "webUrl": "SitePages/Page-3.aspx",
        "title": "Work from home",
        "thumbnailWebUrl": "",
        "reactions": {
            "likeCount": 12
        }
    }]
      },
      "responseHeaders": {
        "content-type": "application/json; odata.metadata=minimal"
      }
    }
  ]
}

It is important to define the absolute URL of the API endpoint. For example, here we define pages to return for a specific site ({site-id}).

Start the proxy and test the application

When you start the proxy, you define its settings depending on what you want to test.

In our case, we want to test successful API calls with mock responses. In a PowerShell console, we enter the following line:

m365proxy --mocks-file {root-folder-path}\ImageCard-MostLikedPages\responses.json --failure-rate 0

Now let’s load our application returning the SharePoint pages with their number of likes defined in the responses.json file.

We can also see on the PowerShell console that the request was successfully interpreted by the proxy.

Summary

In this blog post, we performed the necessary steps to use the Microsoft Graph Developer Proxy to mock API call responses. This feature can be used in multiple scenarios, for example to easily test specific responses or to test how an application handles a large amount of data. It is also possible to define unsuccessful responses with a specific error code to test how the application handles it.

References

Introducing the Microsoft Graph Developer Proxy community preview

Microsoft Graph Developer Proxy

Mock responses

M365 Development · SharePoint

Use Top Actions with SPFx 1.17.1

Content

What are Top Actions ?

Top Actions allow you to add settings to your SharePoint Framework (SPFx) web part just like you would do on the property pane but directly on the web part’s command bar.

Top Actions were introduced in the SPFx v1.16 release (preview). In this blog post we will talk about how to use this feature with the SPFx v1.17.1 release (there are a few differences).

You can choose from two different user interfaces for your top action:

  • Button
  • Dropdown list

How to use it ?

Add Top Action to your web part

To add top actions to your web part, you must implement the getTopActionsConfiguration() method which return ITopAction object:

import { ITopActions } from '@microsoft/sp-top-actions';

export default class HelloWorldWebPart extends BaseClientSideWebPart<IHelloWorldWebPartProps> {

  public getTopActionsConfiguration(): ITopActions | undefined {
    return {
      topActions: [], //List of top action controls you want to add to your web part
      onExecute: (actionName: string, newValue: any) => {} // Method triggered when you select one of the top action
    };
  }

Use button control

To define a button control (TopActionsFieldType.Button) define the following properties in topActions:

import { ITopActions, TopActionsFieldType } from '@microsoft/sp-top-actions';

export default class HelloWorldWebPart extends BaseClientSideWebPart<IHelloWorldWebPartProps> {

  public getTopActionsConfiguration(): ITopActions | undefined {
    return {
      topActions: [
        {
          targetProperty: 'button', // Target property from the web part’s property bag
          type: TopActionsFieldType.Button,
          title: 'Button to show data reports', // Display name of the action (can be used in a tooltip or aria-label)
          properties: {
            text: 'Show report',
            icon: 'ReportDocument'
          }
        }
      ],
      onExecute: (actionName: string, newValue: any) => { 
        console.log(actionName); // value of the targetProperty ('button' in this example)
        console.log(newValue); // true (always the same value for button controls)
      }
    };
  }

Use dropdown list control

To define a button control (TopActionsFieldType.Dropdown) define the following properties in topActions:

import { ITopActions, TopActionsFieldType } from '@microsoft/sp-top-actions';

export default class HelloWorldWebPart extends BaseClientSideWebPart<IHelloWorldWebPartProps> {

  public getTopActionsConfiguration(): ITopActions | undefined {
    return {
      topActions: [
        {
          type: TopActionsFieldType.Dropdown,
          title: 'Select data view', // Display name of the action (can be used in a tooltip or aria-label)
          targetProperty: 'displayMode', // Target property from the web part’s property bag
          properties: {
            options: [{
              key: 'list',
              text: 'List',
              checked: this.properties.displayMode === "list"
            }, {
              key: 'grid',
              text: 'Grid',
              checked: this.properties.displayMode === "grid"
            },
            {
              key: 'chart',
              text: 'Chart',
              checked: this.properties.displayMode === "chart"
            }]
          }
        }
      ],
      onExecute: (actionName: string, newValue: any) => {
        console.log(actionName); // value of the targetProperty ('displayMode' in this example)
        console.log(newValue); // value of the key of the selected option (e.g. : '2' if Grid is selected)
        this.properties.displayMode = newValue;
      }
    };
  }

What about icons for dropdown options ?

You can also add an icon for each option available in the dropdown control using iconProps:

properties: {
            options: [{
              key: 'list',
              text: 'List',
              checked: this.properties.displayMode === "list",
              iconProps: {
                officeFabricIconFontName: "List"
              }
            }, {
              key: 'grid',
              text: 'Grid',
              checked: this.properties.displayMode === "grid",
              iconProps: {
                officeFabricIconFontName: "GridViewMedium"
              }
            },
            {
              key: 'chart',
              text: 'Chart',
              checked: this.properties.displayMode === "chart",
              iconProps: {
                officeFabricIconFontName: "DonutChart"
              }
            }]
          }
Dropdown options with icons

Working sample of code

If you want to try out Top Actions by yourself you can find a small web part sample that I built here: react-graph-webpart-report

References