[MSFT] Rolling out support for Command Customizers in the new UI

[reedpamsft]

What type of issue is this?

other

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

No response

Issue description

Hi All,

I just wanted to let you know that we are restarting the rollout of support for Command Customizers in the new Lists UI. Tenant Admins will have been notified of this through MC891238.

The behavior you can expect is that Lists in Team Sites and in the Lists App which had previously been falling back to the old UI due to the presence of Command Customizers will now start showing the New UI (with the view tabs across the top). This will rollout in a staged manner over the course of several weeks, starting with First Release/Targeted Release users, and then moving through Standard Release tenants. Please let us know if you run into issue where command customizers which were working are now no longer working, as that is the primary reason we've had to halt this rollout in the past.

We are committed to supporting the existing approved SPFX framework API's with this rollout. You may see issues where command customizers which had taken explicit or implicit dependencies on the DOM structure of the page (css classes, element heirarchy, etc.) will no longer function as expected. Please note that the DOM structure is not an API contract and is subject to change at any point (please see https://learn.microsoft.com/en-us/sharepoint/dev/spfx/enterprise-guidance for more details there).

Thanks!

Reed

[VesaJuvonen]

thx @reedpamsft on starting this thread from Microsoft side on the command support with the new lists UX.

If there are any issues you find, please do report in this issue. If you are seeing a same issue like someone else, please do +1 (👍) for the issue. We will be closely following the progress and your feedback as the feature is again rolling out worldwide.

Thank you for your input advance. Feel free to add comments and we'll guide them to the right model - create new issue if needed etc.

[Feets20]

@reedpamsft @VesaJuvonen My team has a question on this rollout, around lists with field customizers. I believe the admin center message referenced above notes that field customizers are not included in the new rollout, but can you help me understand what that means exactly?

If we have lists with both command customizers and field customizers, are we saying that these lists won't be updated at all? Or are we saying that only part of the list will be updated? We haven't been able to find clear guidance on this and we're trying to stay ahead of these updates as they'll have a material impact on our users if our tenant is updated and our code isn't ready for it.

[chrisredman01]

Similar to the question above, we have a customisation that adds a field customizer to the List after a certain action has been performed by the user.

Should we expect that the 'new' experience will apply to the List until the field customizer is added, and then it'll revert to the 'old' modern experience?

(we briefly saw this behaviour in the previous rollout, although it seemed to be cache sticky and didn't revert to the 'old' experience until a hard page refresh was performed)

[reedpamsft]

@Feets20 if there is a field customizer present on a list, the list will continue to use the old UI.

For completeness, there are 8 possible states a list can be in, and I'll present them with the expected state of the UI after this rollout is completed:

No SPFX customizers: new UI (this is also the current state of things)
Application customizer only: new UI (this is also the current state of things)
Command set customizer only: new UI (this is what we're working on enabling)
Field customizer only: old UI
Command + field: old UI
Application + command: new UI
Application + field: old UI
Application + command + field: old UI

I hope that's clear! Let me know if you still have questions.

[reedpamsft]

@chrisredman01 that's an interesting case. Is the field customizer present on the list but hidden, or not present on the list at all, in the initial state?

From a technical perspective, if a field customizer is present on a list, it will render using the old UI. If a list goes from not having a field customizer to having a field customizer, it will go from rendering the new UI to rendering the old UI. There will be an intermediate state there where it will still load the new UI because of caching behaviors, but after a few refreshes it should settle on the old UI.

[chrisredman01]

@reedpamsft - the field doesn't exist on the List until a user does an action through the Command Customiser which calls a custom API to add the field (which is linked to a field customiser) to the list via CSOM. Sounds like it will match the behaviour we saw on the previous rollout.

Fingers crossed that the this.context.listView context is correctly working for lists with folders (#9908). Do you know if that's been addressed?

[reedpamsft]

@chrisredman01 yes, we canceled the earlier rollout in order to address that. We've confirmed with internal testing, as well as with live examples that a few helpful people were able to provide, that it's working. If you are okay providing me with your customizer to test, we can give it a try in our test environment.

[Feets20]

@Feets20 if there is a field customizer present on a list, the list will continue to use the old UI.

For completeness, there are 8 possible states a list can be in, and I'll present them with the expected state of the UI after this rollout is completed:

No SPFX customizers: new UI (this is also the current state of things) Application customizer only: new UI (this is also the current state of things) Command set customizer only: new UI (this is what we're working on enabling) Field customizer only: old UI Command + field: old UI Application + command: new UI Application + field: old UI Application + command + field: old UI

I hope that's clear! Let me know if you still have questions.

@reedpamsft I appreciate the quick reply, that makes sense. I think the only follow up question we have is if there is any plan to roll out this new UI with SPFx field customizers in the future? And if so, when that would be?

[reedpamsft]

@Feets20 we have no publicly available timelines on the support of field customizers in the new UI at this point, sorry.

[araLT]

Hi All! For now I see two issues related to SPFx extensions in new UI:

1. The default CSS styles of icons applied to SPFx list view command extensions are no more affecting on size of icons, which brings to situation when icons of size >16x16 gets outside of boundaries.

For old UI size of icons was changed to 16x16 via CSS appropriate CSS style.

The workaround for now (or later if that part is not going to be made like old UI) could be changing the specified icon size to be exactly 16x16 in extension manifest.

2. The second issue is that SPFx extensions, for which location is ClientSideExtension.ListViewCommandSet.ContextMenu is not loading at all for new UI. So, list item context menu commands added via SPFx extension are not appearing in new UI at all. I just wonder whether it is intended change (i.e. in new UI it will not be possible to add custom commands to list item context menu) or it is something that is going to be implemented yet for new UI.

[SandyLT]

@reedpamsft Is there currently any custom list scenario where the new UI will not take effect eventually? We're currently seeing some lists receiving the new UI and some not on the same sites in our Targeted Release tenant, and we can't see what the difference is, either in list creation date or configuration. Or is it just a matter of time?