Migrating user custom actions and ECB menu items to SharePoint Framework Extensions
SharePoint Framework is a new model for building SharePoint customizations. If you customized SharePoint with user custom actions and custom Edit Control Block (ECB) menu items by using the SharePoint Feature Framework, you might be wondering what the possible advantages of migrating them to the new SharePoint Framework are.
First, let's introduce the available options when developing SharePoint Framework Extensions:
- Application Customizer. Extend the native "modern" UI of SharePoint Online by adding custom HTML elements and client-side code to pre-defined placeholders of "modern" pages. At the time of this writing, the available placeholders are the header and the footer of every "modern" page.
- Field Customizer. Customize the rendering of a field in a list view by using custom HTML elements and client-side code.
Depending on the target of your customization, you can leverage any of the above flavors. For example, the Application Customizers are a great replacement for the user custom actions. Moreover, the Command Sets are an appropriate replacement for the ECB menu items.
Benefits of migrating existing SharePoint Feature Framework customizations to the SharePoint Framework
SharePoint Framework was built thinking about the new SharePoint "modern" experience, which is available on the "modern" team sites and "modern" communication sites, and which targets any device and any platform.
The only supported way of customizing no-script "modern" sites
One of the main benefits of migrating old-school SharePoint Feature Framework customizations to the SharePoint Framework is that it is the only supported technique that you have on modern sites for customizing the UI.
Easier access to information in SharePoint and Office 365
Now, with the SharePoint Framework and the SharePoint Framework Extensions, it is easy and straightforward to consume both the SharePoint REST API and Microsoft Graph. You can now create more powerful solutions, which can consume and interact with the full ecosystem of services provided by Microsoft Office 365.
Similarities between SharePoint Framework solutions and SharePoint Feature Framework customizations
Nevertheless, both the SharePoint Feature Framework user custom actions and ECB items and the SharePoint Feature Framework customizations share some similarities.
Both SharePoint Framework Extensions and user custom actions or ECB menu item solutions leverage an XML manifest file, which is written with the SharePoint Feature Framework syntax. Thus, the deployment is based on the same techniques.
Run as a part of the page
Similar to user custom actions and ECB of SharePoint Feature Framework, SharePoint Framework Extensions are a part of the page. This gives these solutions access to the page's DOM and allows them to communicate with other components on the same page. Also, it allows developers to more easily make their solutions responsive to adapt to the different form factors on which a SharePoint page could be displayed, including the SharePoint mobile app.
Use any library to build your extensions
When building page customizations by using user custom actions, you might have used libraries such as jQuery or Knockout to make your customization dynamic and better respond to user interaction. When building SharePoint Framework Extensions, you can use any client-side library to enrich your solution, the same way you would have done in the past.
An additional benefit that the SharePoint Framework offers you is isolation of your script. Even though the web part is executed as a part of the page, its script is packaged as a module allowing, for example, different extensions on the same page to use a different version of jQuery without colliding with each other. This is a powerful feature that allows you to focus on delivering business value instead of technical migrations and compromising on functionality.
Run as the current user
In customizations built by using user custom actions and ECB menu items, whenever you needed to communicate with SharePoint, all you had to do was to call its API. The client-side solution was running in the browser in the context of the current user, and by automatically sending the authentication cookie along with the request, your solution could directly connect to SharePoint. No additional authentication, such as when using SharePoint Add-ins, was necessary to communicate with SharePoint.
The same mechanism applies to customizations built on the SharePoint Framework that also run under the context of the currently authenticated user and don't require any additional authentication steps to communicate with SharePoint. Of course, the security context is that of the currently connected user, which implies that from a security perspective, you need to be careful when installing any SharePoint Framework Extension in any target site collection.
Use only client-side code
Hosting model self-consistent and based on Office 365
Both SharePoint Framework Extensions and user custom action or ECB menu item solutions can be hosted on SharePoint Online, and eventually in the Office 365 CDN service, avoiding any need for external services or hosting environments.
While hosting SharePoint Framework solutions on a CDN offers many advantages, it is not required, and you could choose to host the code in a SharePoint document library. SharePoint Framework packages (.sppkg files) deployed to the app catalog specify the URL at which SharePoint Framework can find the solution's code. If the user browsing the page with the extension can download the script from the specified location, there are no restrictions with regards to what that URL must be.
Office 365 offers the public CDN capability that allows you to publish files from a specific SharePoint document library to a CDN. Office 365 public CDN strikes a nice balance between the benefits of using a CDN and the simplicity of hosting code files in a SharePoint document library. If your organization doesn't mind their code files being publicly available, using the Office 365 public CDN is an option worth considering.
Differences between SharePoint Framework solutions and SharePoint Feature Framework customizations
However, between the two development models there are also some significant differences, which you should consider when designing the architecture of your solutions.
Run in no-script sites
Because SharePoint Framework solutions, including Extensions, are deployed through the app catalog with a prior approval, they are not subject to the no-script restrictions and work on all "modern" sites.
Pre-defined set of extensibility points
Theoretically, you could create an Application Customizer that uses DOM to completely change the structure of a page, like with user custom actions. Nevertheless, SharePoint Framework encourages a more structured and reliable approach to customizing SharePoint. Rather than using specific DOM elements to customize SharePoint, SharePoint Framework provides developers with specific hooks and placeholders for customizations, and you should use them only.
Use TypeScript for building more robust and easier to maintain solutions
Microsoft is not actively investing in JSOM anymore. If you prefer working with an API, you could alternatively use the PnP JS Library, which offers you a fluent API and TypeScript typings.
Migrate existing customization to the SharePoint Framework Extensions
Reuse existing scripts
Rewrite the customization
If you need to support your solution for a longer period or would like to make better use of the SharePoint Framework, or if it turns out that your existing scripts cannot be reused with the SharePoint Framework, you might need to completely rewrite your customization. While it's costlier than reusing existing scripts, it offers you better results over a longer period: a solution that is better performing and easier to maintain and to use.
When rewriting an existing customization to a SharePoint Framework solution, you should start with the desired functionality in mind. For implementing the user experience, you should consider using the Office UI Fabric so that your solution looks like an integral part of SharePoint.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.