-
Notifications
You must be signed in to change notification settings - Fork 1k
SharePoint Framework v1.7 release notes
Hello, and welcome to SharePoint Framework Release 1.7
This is probably the biggest release in terms of new features we have had since the original preview (or maybe the preview of extensions). Lots of stuff.
Dynamic Data The main feature that reached final release is Dynamic Data. This is an update to the original classic feature around connected web parts. This version should be easier for users and developers alike.
2019 Support You can now target SharePoint 2019 in the generator
We are also introducing several developer preview features.
SPFx for Teams Tabs Leverage your SharePoint Framework skills to create solutions to show up in Tabs for Microsoft Teams.
Teams-based Apps in SharePoint If you are creating a provider hosted app, you can use the same solution that you created for Microsoft Teams and use it in SharePoint.
Full page apps As a developer, you can create modern pages with the same look and feel as the rest of the site, where the main body of the page is a single large webpart.
Domain Isolated WebParts If you create SPFx solutions that require different permissions that the rest of your tenancy, you can now host them in their own domain with their own permissions while still leveraging all of the SharePoint framework (without having deal with creating a provider hosted app).
ListSubscriptions in the browser Get realtime notification delivered to your component when changes occur to registered document libraries.
Update to ContentPlaceholder lifecycle While rolling out some recent SharePoint updates, we noticed that a number of SPFx solutions were written in a problematic way and had trouble handling placeholders. We've reworked the lifecycle of the ContentPlaceholders to make them more resilient to this.
Remember to use the --plusbeta option in the generator or reference the -plusbeta versions of the packages in your package.json file.
For the Dynamic Data feature, we've made a number of improvements in the GA (general availability) work.
The main bulk of the additions between developer preview and GA are around the property pane. There are a variety of classes introduced to support this, including
-
IPropertyPaneConditionalGroup, which allows you to have different groups appear based on some condition -
IDynamicDataSharedPropertyConfiguration,IDynamicDataSharedPropertyFilters,IDynamicDataSharedSourceConfiguration,IDynamicDataSharedSourceFilters,IPropertyPaneDynamicFieldSetProps, that can be used to create controls in the property pane that allow authors to pick a dynamic data source and property. - We have deprecated (and will remove completely in a future release) the developer preview
IPropertyPaneDynamicTextFieldPropsinterface andPropertyPaneDynamicTextFieldfunction that was the quick-and-dirty way to edit a dynamic property. - We've updated the
IWebPartPropertiesMetadatainterface to allow a developer to declare webpart properties as dynamic, which allows us to create theDynamicPropertyobjects for you at web part creation time.
On the underlying data side of things, the DynamicDataSourceManager now exposes the sourceId of the datasource (useful in debugging). A data source can now provide a getAnnotatedPropertyValuecallback that will be used to display localized strings and sample data to the end user. Finally, when calling the DynamicProperty object to get the current value of a property, you can call tryGetValue() which returns a single property, or tryGetValues() which will return an array. This is quite useful when a given datasource might return one or many objects (for example, the selected items of a list web part), and you always want to support multiple properties. For both scenarios, the framework will make sure that you get a single object or an array, independent of what the underlying datasource exposes. This can be useful if you are creating a webpart (say a people card), that always expects to display a single person. You can have the author pick the current user from the context datasource, or you can have the user pick the author from the selected item of a list web part. As the developer, you only have to call property.tryGetValue() and you will always get back a single value (or undefined).
The first built-in datasource is the page context data source. It is a simplified version of the current PageContext object, returning things like the current user, list, site, etc. Other data source (like the list / document library web part) will follow.
When you target 2019, you get public/GA feature set from the 2019 product. This is the public/GA code from version 1.4.1 of the framework
You can now create teams tabs solutions using SPFx. All the build tools, packaging, hosting, CDN and authentication stays the same. There is now a property available on the context object called microsoftTeams that exposes the Teams sdk object. From there, if your solution is being hosted as a Teams app, you will have access to the full Teams context object, containing things like the team name, ID, channel, etc. Just side-load a teamsApp.zip file with the manifest we provide in the Yeoman generated project. For more information, you can look at the latest tutorial here (link coming soon)
If you have created a provider-hosted teams tab solution, you can now upload the solution directly to the SharePoint app catalog, and the tab will be available as a webpart. The latest teams sdk has a SharePoint context object available that provides the same PageContext object that you have access to in SharePoint (the initial release of the teams SDK has it typed as any, a future release of the sdk will have the full interface. However, the object will be the same). For a better experience, you can host this provider hosted app in the new Full page app feature.
One thing that has been asked for quite a while is the ability to create full page apps in SPFx. We think we have a better solution, which is to create a page layout that hosts a single webpart that covers the entire content area of the page. Things like navigation and the header still exist, and follow the form and style of the rest of the site (so an app page in a communications site won't have left nav, while an app page in a teamsite will). In the future, as extensions expand and allow for other customizations, those customizations will carry over. This will mean that you as a developer only need to focus on your content, and not do a bunch of work to try and make the app page look like every other page in the system, handle fast-page navigation, handle application customizers, etc. There is a property on the BaseWebPartContext object called formFactor that will let you know if you know if you are full size or standard. To create an app page, see here. (Link coming soon)
From the beginning of SPFx, we've always stated that iFrames have a purpose, but that the primary solution didn't need them. Now that the framework has matured, it's time to unlock the scenarios where iFrames were important - namely, when you need a different level of permissions for a webpart than the rest of the page/tenancy. Building on the Web API feature from 1.6, by setting the isDomainIsolated property in your package-solution.json file tp true. When you do this, all webparts in the solution will run in a separate domain with it's own set of permissions. The framework will handle the creation of the iFrame, passing data back and forth to allow the property pane to work correctly, etc. You manage the permissions for this solution in the same admin page that you manage the SPFx permissions for the rest of the tenancy. In this developer preview, dynamic data across webparts from the main page and a domain isolated webpart is not supported.
The newly published @microsoft\sp-list-subscription package allows you to register for browser events when an underlying library is updated. You provide the library information and a callback function, and when the library is updated, your callback will be called. See this tutorial for a full example (Link coming soon)
We have reworked the ContentPlaceholder lifecycle events. Now, whenever you create a content placeholder, it will succeed. However, if the current page doesn't have a place for the placeholder, the placeholder won't render. Once the user navigates to a page that does support the placeholder (or the placeholder support becomes enabled on the page after the PlaceholderContent has been created), we will display it. A new property on the PlaceholderContent object, isVisible will let you know if the placeholder is being displayed. Additionally, when the visibility of placeholders change, we will call a method on the ApplicationCustomizer called onPlaceholdersChanged. If you wish to be notified of these changes, you can override the method.
We have made a couple of methods on the SPComponentLoader public. getManifests will return the list of manifests that the loader is aware of, and loadComponentById will load a component by id from the server if it is not already loaded (and return it to you).
We have removed support for Node 6 in this release.
As usual, update your package.json files to point to the 1.7.0 version. If you are migrating from a version earlier than 1.6.0, you'll need to make the changes laid out in the Build and Tooling changes section of the 1.6.0 release notes.
We found an issue at the last minute in dynamic data that you should be aware of. If you have a producer that returns a property that is an array (the actual property from the producer, not a subproperty), the property pane incorrectly sets the reference in the DynamicProperty object. For now, avoid having a property return an array. A fix will be coming soon and we will notify people when it is rolled out.
The Teams SDK currently does not have the full typing for the SharePoint context. That will be updated shortly.
Reconfiguring the SPFx solution in a Teams tab is not supported at this time. The default manifest file in the teams directory that yeoman creates has the canUpdateConfiguration property set to false to avoid the problem.
-
Getting Started