The Future of Command Set Extensions

[AJIXuMuK]

We are starting this discussion to collect thoughts on the present and future of Command Set Extensions.

Current State

We're aware of the issues around Command Sets.
Some of them have been already fixed or will be fixed in the next few drops (#1201, #1242, #6891, and others).
Some of them couldn't be fixed with the current architecture in place (#4056, #4882, #6252, etc.).

The main reason for that is confusion around the onListViewUpdated event.
Based on the name, developers assume the event should fire when some list view update appears: navigation between views, drill up/down from/to a folder, selection, etc.
But the actual purpose of the event handler is to check if the commands are available in the current specific state. It leads to few limitations that are also confusing for the 3-party developers:

• The only property that could be updated in onListViewUpdated is visible. Changes to title will not take effect.
• The handler could be called for the command set N times for a single event, where N - number of commands in the command set.
• List engine decides when to call the method based on internal state and caching, meaning it can be called only once when navigating between views

The Future

We understand the current state doesn't meet all the goals and want to improve it based on the received feedback.

First thing to mention, for backward compatibility, we will still support the current model.
But in parallel, we want to provide a better way to implement Command Sets.

Here is early thinking:

1. onExecute remains the same, with the ability to update properties of the commands in the command set, as well as execute any LoB operations
2. promote onGetState - handler that will be called for each command in the command set and provide the ability to request rich context of the list/document library state: current list (id), view (id), folder... This handler will still be called based on internal logic/caching and cannot be treated as navigation or any other type of event.

What we want to hear is your feedback, additional proposal, and use cases for Command Sets.

Please, when sending feedback, assume that Application Customizer and Field Customizer have needed context and events and Command Sets will not be enhanced to provide workarounds to fix missing parts of other extensions.

Appreciate the feedback to come!

[thechriskent]

So happy to see these getting some attention and the openness of the discussion. Great job!

My Command Set Wishlist (in order of priority):

• Fluent UI Icon Support: Command set icons should be set with a iconName property similar to how webparts can be. (Using UI Fabric Icons for ListView Commands #642)
• Teams Support: Command Sets should show up in the Files tab for a team along with showing up for any added list/library tabs. It's super weird that they don't already. Having teams context would also be needed in these cases.
• Tooltips: Commands should have a configuration to specify text for the tooltip
• Removal via UI: Once a command set is added to a site it can only be removed via the API/PowerShell. That's a big limitation and is a missing part of the self-service model available now. Users can add an app, find the command set, and add it to their site right from the UI. But they have to put in an IT ticket to get it removed even if they are the site owner.
• Sub Menus: Command Sets should have the option of child commands like many of the icons in the command bar. Their ability to show or not show should still follow the same logic as the primary command.
  • Support Checked: In addition to what's available for the primary command, sub menu items should have configuration for an icon (Fluent UI or Image URL) and the ability to mark as checked or not.
  • Sub Menu Style: Ideally we could specify that the primary command be a split button (clicking on the main will execute a command with a separate dropdown to the right) or just have sub menu where only the sub commands have an execution

• Additional Command Sets: Listview command sets are awesome! But there are lots of other locations I would love to be able to add a command. Here are a few:
  • Settings menu (Gear)
  • Site Contents Command bar
  • Site Contents New Menu
  • Site Contents Context Menu
  • Page Command bar
  • App Bar
• List and List Item Refresh: Option to request a refresh of all the list data or just the refresh of an individual item(s). (ListView Refresh from ListView Command Set #818)
• Disabled: A command being visible or not is cool, but I would often like to leave it visible and just have it be disabled. It's hard to tell users to use it when it only shows up under certain conditions that won't always be obvious to an end user. So being able to specify disabled with a tooltip that tells users the conditions the command can be used would be a big improvement. Although, not sure this matches how the other commands in the command bar work (though they should).
• View Context: Details about the view such as view name, URL, and Id should be added to the context
• Custom Action in List Formatting: An awesome feature of List Formatting is to have a custom action of executeFlow this allows the flow execution to happen directly from a list item instead of using the command bar. This makes things far more obvious for users (in fact, I've stopped telling people to select the item then look in the Integrate > Power Automate menu to see if the configured flow shows up. I just make a button display using formatting logic when it makes sense). Having the ability to specify a custom action of executeCommand with parameters to specify the command set id and the command name would be really powerful.
• Some other type: Why is their a type property in the manifest that only supports command? Either this should be extended or just removed altogether

Recent use case

I recently built a command set that provides integration with Microsoft Cognitive services to provide document translation directly of the documents in your library. Works great but the fact that Teams users have to choose Open in SharePoint first is SUPER frustrating.

[AJIXuMuK]

What a great start!
Thank you @thechriskent!

Could you elaborate a bit more on list refresh? Currently the list is refreshed automatically every few seconds if there are changes to the items.
Do you need this refresh for some other scenarios?

[kjetilg]

Teams Support.
This is crucial, now that more and more people use the Lists and Document Libraries primarily inside of Teams.

We do a lot of business process and automation scenarios using Command Sets and Field Customizers to give users an entry point to start a process, for example around a document, where we need a customized UI and can't use Flows.
The ability to use the Teams Context in these cases would be good. At a minimum the possibility to check if it's running inside Teams or not.

It's really hard (close to impossible) to try to explain to end users why these things can only can be done if you open the List / Document Library in a SharePoint view, as they expect it to be available inside of Teams as well.

[phillipharding]

While less of an issue for me, I've noticed that sometimes the list just doesn't auto refresh, at least in a timely manner - the ability to refresh the item or list would be super cool, and I notice that the Teams ➜ Files tab has a "refresh tab" button 🤓

[thechriskent]

The original issue mentioned above was submitted before the list subscription / live updates features. Those are awesome and make a big difference. But... as @phillipharding says it isn't super reliable. If an update to a list item always resulted in that item getting refreshed immediately then I would agree this feature isn't needed. But that definitely isn't the case and having an extension that makes changes to list items that don't refresh creates a very bad user experience and so the only option is to go nuclear and just refresh the whole page

[AJIXuMuK]

I probably see another scenario here as well.
If the command set applies field customizer to some column - probably the list will not refresh in that case.

[patrikhellgren]

I also agree that the document library live updates is a nice feature but we also need a way to trigger a view/row/field update just like is done when you update metadata fields from the information panel but that seems to be done with some kind of undocumented internal method. A few years back there was a hack mentioned in #1449 to accomplish this but that didn't work for long.

Here is an example of the kind of delay that we are seeing with the current live updates. When I click the command bar button an azure function is triggered that copies the file to an external system and then sets the Doc Number field (which is a standard number field) while reporting the status to a field customizer in the Status field via Signal-R. As you can see the status is reported as finished in a few seconds but the Doc Number field view takes a looong time to update (as this is done via the built-in live updates and nothing we can trigger). The copy itself takes around 10 sec but it takes another 40 sec for the view to update so hang in there, the image isn't frozen. The delay varies from sometimes around 10 sec to around 60 sec so I wouldn't agree that it refreshes automatically every few seconds, that I have never seen. In this case if I were to reload the page after the status is green the number is there so it is a view refresh delay.

Very annoying for the users as they start thinking that something is wrong as it takes such a long time to update the field view.
This is a case where we would benefit from being able to trigger the view update from the Command Set extension or field customizer.

[joelfmrodrigues]

Wow, great initiative to move this forward and Chris pretty much summarised everything I would submit.
One thing that I would like to add (think it's not on his list) would be the ability to define a specific order for the command to appear. I understand this would be limited as some OOB commands would always appear first to give more relevance to those commands, but still feel that more control could be available.

[joelfmrodrigues]

@AJIXuMuK exactly, and I completely anticipate that everyone would create solutions that would try to show first, so passing that decision to the admins sounds like a reasonable approach.

[patmill]

Has anyone tried to use the sequence #? The underlying registration mechanism is the same (ie, the customziations are registered in the same way as classic custom actions)

[phillipharding]

I tried a while back, it didn't have any effect

[joelfmrodrigues]

Same here, tried it a while back and seemed to make no difference

[patrikhellgren]

It would be great if we could change the order but it would be event better if we could hide the default buttons. Lists and document libraries are so powerful these days with command set extensions, field customizers, view customizations and so forth that we can use them as full applications if it weren't for the default buttons that always confuses the users. I always get questions about these buttons like: "Sync - What does that do, does it sync with system X", "Add shortcut to OneDrive - Why should I add a shortcut to this contract to my OneDrive" and so forth.

[patmill]

One more thing to add here, when the customization is executing, we need the context of the list surfaced. For example, if you have a list webpart, the page context will have the pages list as the list ID, not the list represented by the webpart.

[thechriskent]

Related (since this context problem is the very issue I'm trying to fix in my current project), the webpart doesn't utilize the debugManifestsFile query string stuff so there is no way to test how your commandset works in the webpart without deploying. This is super annoying when trying to track down a bug that only surfaces when used from the webpart.

Not sure that's something the SPFx team can tackle directly, but it's definitely a gap. My workaround currently is to build the bundle and package the solution without --ship so that things are loaded from localhost. It works because I've got a site with a site collection app catalog where I can do that sort of thing, but it's a huge pain and my solution won't work for everyone depending on their environment/policies.

[hugoabernier]

I may be late to the party, but I would love to see extensible command sets in Pages, not just libraries.

For example, let's say that I want to add a button to allow page authors to run through an accessibility checker by clicking on a page button, or trigger a page translation process, or verify page content for compliance with communication guidelines, etc.

Right now, they'd have to save the page, go to the list of pages, select the page, and trigger the command, instead of doing it within the page itself.

Another thing I would suggest is that you take a look at how Dynamics/Power Platform handles adding custom commands to model-driven apps. Of course, the implementation/engine behind it would be different for SharePoint, but they've already done some thinking in terms of functionality that may inspire you.

[phillipharding]

but I would love to see extensible command sets in Pages, not just libraries

Brilliant, love that idea 🤓🎉

[patrikhellgren]

I agree with everything said above but would like to add a few things:

• ECB menu - there I would also like to order the items, use submenus and preferably hide some default commands.
• Enable for specific Content type - I would like to have specific commands enabled for specific content types
• Enable for specific File type - I would like to have specific commands enabled for specific file types

I know we can accomplish the last two programmatically but built-in support would be preferred.

[cwdata]

And - being able to disable the existing OOTB commands would be super helpful too.
Imagine you're building an extension to show a customized form for editing or creating list items. Works pretty well with SPFx, but, how do you tell people to click on your edit button instead of the default one???

[thechriskent]

Adding additional customization options to the list/library settings (would love to get a modern refresh on these pages with some new options) would be great! However, I don't think any of that should be done with SPFx. Those should be configuration options. (Would definitely love to see the option to specify SPFx for customized list forms, but that would be done with something other than command sets)

[patrikhellgren]

Localization support should be better and in line with the rest of SPFx localization. Today we have the json options in the manifest file but that doesn't work with the standard SPFx localization option. The way we have solved this today is to set the command title to the localized string in onListViewUpdated which so far seems to work perfectly.

[AJIXuMuK]

@patrikhellgren - inability to localize a title using json is a bug. It will be propagated pretty soon (could already be on your tenants).

[patrikhellgren]

@AJIXuMuK Great that that bug is being fixed but I was probably a bit unclear, I was thinking about that it would be nice to localize command set labels like we do with all other localized strings like:

import * as strings from 'HelloWorldCommandSetStrings';
...
Dialog.alert(`${strings.Command1}`);

I know we should be able to use something like the following (which is then hopefully fixed in the fix rolling out):

    "COMMAND_1": {
      "title": { "id": "$HelloWorldCommandSetStrings:HelloWorldCommandSetStrings.Command1;" },
      "iconImageUrl": "icons/cancel.png",
      "type": "command"
    },

This is however not in line with the other way and we don't get proper intellisense for the strings and so forth.

[AJIXuMuK]

@patrikhellgren

For the declarative localization in the manifest you will be able to specify all the languages like:

"title": {
  "default": "My String",
  "en-US": "My String",
  "fr-FR" "My string in French"
}

But you can also use code and strings in there. I believe you can set the title of the command in onInit based on loaded strings.

[joaojmendes]

I don't know if someone already reported this but I'm leaving here my suggestion ...
allow the commandset will be activated only for specific list(s) and not for all list type, as is the commandset is always load and if you want activate to specific list we need to on code control the visibility , always pass the listId as parameter to the extension and in code control ...

thanks.

[AJIXuMuK]

@joaojmendes - could you clarify the requirement?
Currently you can assign a custom action to the specific list using REST/PowerShell.
Do you mean providing the same functionality using Feature Framework?
I assume (but hasn't tested) that it is possible to if the list definition is included in the SPFx package.

[patmill]

This was mentioned in a bug (#4449) a while ago, dealing with async updates to command set state.

[AJIXuMuK]

Updating this thread.
We've released SPFx 1.14.0-beta.5 that contains some changes for the Command Sets we're discussing here: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/release-1.14#list-view-command-set-updates.
In few words the changes cover next issues and requests:

• extended ListViewAccessor - now you have access to such info as list, view, filters, folder, etc.
• new listViewStateChangedEvent event that is much more predictable and helpful than onListViewUpdated
• BaseListViewCommandSet.raiseOnChange - allows to deal with async updates to the command set state. NOTE: use it carefully, frequent calls can lead to low performance of the list

[jimmywim]

Does that point mean we can asynchronously update properties of a command set item? E.g. I want to fetch some info about a file that is selected and then show or hide the button based on that file's item properties.

[AJIXuMuK]

@jimmywim - it does.
Here is the simple sample:

 private _onStateChanged = (args: ListViewStateChangedEventArgs): void => {
    setTimeout(() => {
      const twoCommand: Command = this.tryGetCommand('COMMAND_2');
      twoCommand.title = this.context.listView.list ? this.context.listView.list.title : 'no list data';
      this.raiseOnChange();
    }, 2000);

  }

[russgove]

How about making them work on Onedrive?

[joaojmendes]

Hi Alex, Maybe I wrong, but I think is not possible to specify a specific list the command set will be available, we only have the “ListTemplateId” in ClientSideInstance.xml Or we can use define in elements.xml on the registration of custom Actions ? [A screenshot of a computer Description automatically generated with medium confidence][Graphical user interface, text, application Description automatically generated] Thank you very much. João From: Alex Terentiev ***@***.***> Date: Friday, 28 January 2022 at 14:27 To: SharePoint/sp-dev-docs ***@***.***> Cc: João Mendes ***@***.***>, Mention ***@***.***> Subject: Re: [SharePoint/sp-dev-docs] The Future of Command Set Extensions (Discussion #7375) @joaojmendes<https://github.com/joaojmendes> - could you clarify the requirement? Currently you can assign a custom action to the specific list using REST/PowerShell. Do you mean providing the same functionality using Feature Framework? I assume (but hasn't tested) that it is possible to if the list definition is included in the SPFx package. — Reply to this email directly, view it on GitHub<#7375 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC7YHVJINDBD2NV45DUD33LUYKRUJANCNFSM5FMVVPPQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[AJIXuMuK]

I thought you can define custom actions in ListInstance xml. But I was wrong.
And CustomAction element doesn't support this kind of registration type.

So, unfortunately, as there are no huge investments in Feature Framework - I don't think we'd be able to implement that :(

[joaojmendes]

Thank you Alex for the feedback 😊 From: Alex Terentiev ***@***.***> Date: Saturday, 29 January 2022 at 20:24 To: SharePoint/sp-dev-docs ***@***.***> Cc: João Mendes ***@***.***>, Mention ***@***.***> Subject: Re: [SharePoint/sp-dev-docs] The Future of Command Set Extensions (Discussion #7375) I thought you can define custom actions in ListInstance xml. But I was wrong. And CustomAction element doesn't support this kind of registration type. So, unfortunately, as there are no huge investments in Feature Framework - I don't think we'd be able to implement that :( — Reply to this email directly, view it on GitHub<#7375 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC7YHVOMKB66A7DB2HUADIDUYREIJANCNFSM5FMVVPPQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[AJIXuMuK]

Additional update: the latest published version introduces disabled property for the Commands in the Command Set!

[thomaswidmer]

I would like to access the "Publish" command. Unfortunately it does not seem to be integrated in the commands in the basic formatting function set: https://docs.microsoft.com/en-us/sharepoint/dev/declarative-customization/view-commandbar-formatting

[rzklava]

There is a support for command bar customization for OOB options as mentioned in the below link:

Microsoft support for command bar customization using JSON

Any possibility that we can configure the options for custom list view command sets as well?

[AJIXuMuK]

@rzklava - could you please describe your use case?
With SPFx you're completely in charge what buttons are visible and how they look.
So, why do you need additional JSON properties on top the code?

[rzklava]

Hi @AJIXuMuK , in my case, I want to order the command set button, which we got in the command bar. For ex, I want to render the SPFx extension at position 1. Secondly, I want to render the command as button like we have OOTB new button in the list view. These two use cases are there with me as of now.