 Microsoft released an update to the SharePoint framework, SPFX, with version 1.17. This release includes approximately 20 changes such as features that are now generally available, API and SDK improvements, dependency updates, and improvements to the developer experience. However, just over half of these changes are listed in the official release notes from Microsoft. But in my research, I found an additional 40% of changes throughout this release. In this video, I'm gonna cover all of these changes so you can get complete details on the SharePoint Framework 1.17 release. And to help you navigate the content, I've included chapters that you can use to jump to specific topics, which are linked below in the video. As a bonus, I'm giving away a license to my new course, Building SharePoint Framework Web Parts and Property Pains to one lucky viewer just like you. I'll explain how to enter later in the video, so be sure to watch till the very end. Hey, I'm Andrew, and if you're new here, be sure to hit that subscribe button and notification bell to see when I publish new videos for web and cloud developers on things like this SharePoint Framework. And also, if you want insights and news in the Microsoft 365 and Azure developer space delivered straight to your inbox, join the 10,000 plus fellow web and cloud developers who've subscribed to my newsletter. You can find the link in the description below the video. All right, let's get started. I'm gonna break this video down into a couple main sections. First, we'll examine some changes related to the different SharePoint Framework components that you can create. Next, we'll take a look at the changes to the SharePoint Framework APIs and SDKs. And then finally, I'm gonna go over a handful of changes to the developer experience and changes to all projects, such as the generator and their dependencies. So let's get started with the changes to the components. Specifically, let's start with web parts. The SharePoint Framework 1.17 release includes two features that are specific to web parts. The Property Pane link control that's available to developers in the Property Pane was missing an accessibility property, the ARIA label property. This property allows developers to describe an interactive element which is useful to screen readers in an accessible scenario. It seems that this was an oversight dating back to the early days of the SharePoint Framework as a lot of other controls already have this property. However, it appears that this property is also missing from the Property Pane checkbox control as well. Shouldn't that get the same property? I think so and if you agree, I've added an issue for that control in the SharePoint Framework issue list. So check the link in the description or jump to the issue and give it a thumbs up reaction to increase visibility with Microsoft so we can get that fixed in the next release. Now Microsoft introduced a new way to interact with web parts in the SharePoint Framework 1.16 release with top actions. Although previously a developer preview, these controls are now generally available in this SharePoint Framework release. Now the purpose of these controls is to provide an alternative to editing web parts from the Property Pane. Now in my opinion, I've said this before, top actions are probably the first step towards eventually completely replacing the Property Pane. Now when you add a web part to a page and you put it into edit mode, you're gonna see either a button or a dropdown control that you can click. And by handling the click event and the code, you can execute any desired action that you want. Now unfortunately, creating top actions is a little tough because they don't seem to work in the SharePoint hosted workbench. The only way I was able to see them work is when I packaged and deployed the project to my SharePoint site and added to a real SharePoint page, kind of the same way we have to do with extensions. Now when Microsoft released this feature in the SharePoint Framework 1.17 release, they included some of the docs that are, well, they're pretty sloppy. They include code samples that simply won't compile because they reference things in the API that don't exist. And furthermore, some of the aspects with how top actions work, that kind of conflicts with the API documentation. Now I've submitted some issues to the SPFX issue list to get some clarification on these things. I've got all these issues linked to in the pinned comment below the video. And if Microsoft updates these things, I'll be sure to update that comment as well. So keep an eye on that. If you're interested in learning more about top actions, let me know, drop a comment below. I'm already planning to add a lesson about it to my web parts chapter that's in my Mastering the SharePoint Frameworks course and in my Building Web Parts course. But I might even create a video for it and drop it here on my channel if you're interested. But I kind of gotta get some feedback on how interested you are in those. So again, drop a comment below if you wanna see a video on top actions. Now next up, let's talk about adaptive card extensions. We got a few updates here, including one minor thing that I found in my research that was not included in the release notes. Now Microsoft has upgraded the version of the adaptive card schema that's supported by ACES to version 1.5. And this is a significant update as ACES have only supported the 1.3 adaptive card schema up to now. It's also overdue as the 1.5 adaptive card schema was released in October of 2021, which is about a year and a half ago. So what's new in this update that wasn't available before? Well, the 1.4 schema added support for a refresh and authentication property that defines how a card can be refreshed by making a request to a target abort and sending it to enable an on behalf of sign on or just in time authentication for OAuth. Now the 1.5 schema includes several improvements to adaptive cards, such as the support for right to left rendering of the container and column types, the ability to mask the test text input control for scenarios like passwords, support for overflow for an action set when you wanna show more actions than the rendering is gonna support, support for a tool tip on actions to give the user a hint on what the action does, update the input choice set to support a static list of choices, updating actions to support disabling a button and the ability to render tables of data which might be the biggest improvement yet, if you ask me. Refer to the adaptive cards.io website for detailed information on all of these features. Now all card implementations contain an on action handler that you can use to handle actions submitted on adaptive cards used in the two different views available on ACEs. Now in this release is gonna add a new before action handler that's raised before the action is actually executed. You can't change the flow of the action but you can do some things like add extra logging or telemetry to your solution. That's gonna go on that hub class that you have for your adaptive card extension. Now this release also includes an accessibility improvement for the ACE quick view. A new property called focus parameters has been added to the quick view class and that's gonna enable us to set the focus on a specific control in the adaptive card. Now by default, the first control in the card has focus but I can now change that using this property. To do this, I'm gonna override the focus parameters accessor method and I'm gonna return an object of type I focus parameters. And this interface contains two properties. The first is a required property called focus target that returns the ID of the element in the adaptive card that should have focus. And an optional property called aria live that is three options that you can set for screen readers. This can be set to polite, which is used by the screen reader when the user is idle, assertive, which is gonna disrupt any announcement in favor of this property or off, which tells the screen reader not to read the contents. Now at the time of the release, this feature is not supported in Viva Connections mobile app experiences. It's only supported in the desktop and the web browser experiences for Viva Connections. Now another noteworthy change that was not included in the release nose is the default ACE project icon. The SharePoint logo was previously used as the initial icon for the control in the Yeoman generator. But in the SharePoint Framework 1.17 release, the SharePoint logo SVG file that was removed from the default project and it was replaced with a reference to the hosted Viva Connections logo that Microsoft hosts in their online resources. Now that we've reviewed the changes for the different SharePoint Framework component types, let's take a minute and let's look at some of the API and SDK changes as part of this SharePoint Framework release. Now, this new capability was added in the SharePoint Framework 1.17 and frankly, it's not something that most people are gonna encounter. If you don't understand what I'm talking about, you likely aren't gonna need it. But there may be one scenario where you'll think, oh yeah, this unblocks that one problem that we've got. This is for you. Let's first understand the scenario that this feature addresses. When you request an access token from an OAuth provider like Azure AD for a resource, the owner of that resource may have configured it so that you must include specific claims when you request the token. For example, the endpoint may require the user that's requesting the token to perform two-factor authentication or not satisfy some conditional access policy. If you request an access token without that claim, the resource and Azure AD will respond with a claim challenge that indicates that the access token you sent has insufficient claims. So to get past this, you need to include a claim in the token request. But until the SharePoint Framework 1.17, the API, specifically the AAD token provider API, that didn't give us a way to do this. But now we have the method on that object, the AAD token provider has a method called getToken. That's only available in the SharePoint Framework 1.17 and it supports an option object as a second parameter. And we can use this to preempt the claim challenge with a claim parameter that's going to be expected. So in this example, I'm including a claim parameter that satisfies a conditional access policy requirement. You can learn more about claim challenges, requests, and the client capabilities from the Azure AD docs. I've included a link to this in the description of this video below. Now the other improvement to the AAD token provider object in the SharePoint Framework API is support for the pop-up flow. Again, just like last time, let's first understand the scenario that this feature is addressing. Let's say that you've created a SharePoint Framework web part and it needs an access token to call some API. Normally, things work just fine. You're already signed into Azure AD in order to access SharePoint Online so the SharePoint Framework can just leverage the authentication cookie and your request to validate your identity. However, in our newish security-minded world, browsers now support blocking third-party cookies that were commonly used to track user actions across sites by these different ad platforms. And unfortunately, this affects authentication scenarios that use that same technology. So when a token is requested and Azure AD doesn't know who you are, it has to prompt you to authenticate. Usually this can be handled with a redirection, prompting you to sign in again, but that doesn't always work. For example, if your SharePoint Framework web part is used to implement a Microsoft Teams tab and it's rendered within an iframe, the redirection won't work because Azure AD won't allow its sign-in page to be hosted within an iframe to protect against clickjacking. Or if you're using the web part in SharePoint Online and if a user is using Safari with the intelligent tracking protection, ITP, if that feature is enabled, it blocks third-party cookies. So when your web part requests an access token, the only thing that SharePoint Online can do is force a full page refresh, which isn't a great experience. Now, until the SharePoint Framework 1.17, the token provider API didn't support a pop-up experience, but now it does. To take advantage of this, you need to set the argument is enabled app-off-pop-up-enable. That property is available to us on our tenant. We have to set that to true and we're gonna do that using the SharePoint Online PowerShell using the set-spo-tenant PowerShell commandlet. Now, once I set that, I can then implement an event handler on the pop-up event that's on the AAD token provider. Now, I can then use that to initiate the pop-up experience because most pop-ups are gonna be automatically blocked by browsers unless it's initiated by a user gesture. Now let's discuss some of the SharePoint Framework API changes that are related to Microsoft Teams. The first update is an update to the Microsoft Teams JavaScript SDK. Before SharePoint Framework 1.17, we were using the Teams JavaScript SDK version 2.4.1, but with this release, we bumped that up to 2.9.1. Now, this is gonna add support for that live share API that a lot of people are interested in. Also, the Sync to Teams feature in SharePoint Online's tenant app catalog, that can take advantage of a SharePoint Framework solution that contains components that can be used in Microsoft Teams and automatically create and deploy the Microsoft Teams app package automatically for developers. Now, prior to the SharePoint Framework 1.17, the app manifest that Sync to Teams used was based on version 1.8. And what that meant is that if you wanted to use a feature in Microsoft Teams that was implemented with your SharePoint Framework components, like something like a meeting app, you had to manually create the Teams app manifest and package it up rather than rely on the Sync to Teams capability that we have in the tenant app catalog. But in coordination with the SharePoint Framework 1.17 release, the Sync to Teams feature now uses the latest Microsoft Teams app manifest, version 1.16. You don't have to do anything to take advantage of this. It's actually not even part of the SharePoint Framework release, but rather this change was to a feature in SharePoint Online that was just time to happen alongside the SharePoint Framework 1.17 release. Now, this next feature is quite an edge case. Now, when you're using the SharePoint Framework web part as a Teams tab, if your web part displays a SharePoint page, you need to configure the web part to force its rendering within an iframe instead of rendering it within a div element like it normally does. So to do this, there's now a property called support self framing in Teams on the web parts manifest. Now let's try something new and run a little contest. I'm going to give away a lifetime access to my new course on building SharePoint Framework web parts, building SharePoint Framework web parts and property pains. That contains 39 lessons and is over five hours long and you'll continue to get the updates that I add to it over time. So how do you enter? Let's test your SharePoint Framework knowledge. Can you name a feature that's still in beta or developer preview as of the 1.17 release? If you can, drop a comment below and make sure you put the word contest in your comment so I can easily find it. Now I've identified a handful of SharePoint Framework features that are still currently in beta or developer preview roughly a week after publishing this video on Monday, April the 17th. I'll look at all the correct answers and pick someone at random and I'll get back to you by replying to your comment. Bonus points go to those who list the name of the feature that's been in beta or the developer preview the longest. Okay, now let's get back to the SharePoint Framework release. Now the SharePoint Framework 1.17 release includes a few changes to the tooling and the developer experience. The first one's a nice productivity improvement. Previously, when you create a new SharePoint Framework project, you needed to manually update the serve.json file in the projects config folder to point to the domain where your SharePoint online hosted workbench was that you wanted to test your component against. That was a pain because you had to do that every single time in every single project. However, now that string that we use to have the one with enter your SharePoint site in the URL that's been updated to include a string tenant domain. Now, when you run the gulp serve task it's gonna look for an environment variable called spfx serve tenant domain that's been set on your workstation and use that to replace the tenant domain string. Now any project you run, even one that's created by a colleague or one you pull off GitHub, it's gonna use your preferred hosted workbench without any extra effort. That's awesome, so much nicer. Now I noticed a small change that was not included in the release notes. Previously, when you created a new project the generator would say, welcome to SharePoint online. Let's create a new SharePoint solution. But now, as part of the shift to from SharePoint to Microsoft 365, it now says, welcome to the Microsoft 365. Let's create a new Microsoft 365 solution. However, when your project is done creating the last confirmation message, it still shows the SharePoint logo in an ASCII art indicating that they kind of forgot to change that to the Microsoft 365 logo. Now lastly, let's cover the core project dependencies that were updated. There's nothing you need to do here. All of your new projects automatically receive all of these changes when you create a brand new project. You will have to do this if you upgrade a project though. Now note that none of these dependencies are listed in the release notes at the time of this video was published. The OfficeUI fabric package, that's part of FluentUI, that's been updated to version 7.204.0. That's the latest version as of the release of this SharePoint framework. This was just a small bump from the previous version of 7.202 that was found in the previous version of SharePoint Framework, 1.16.1. Also, the RushStack compiler that we is used by the build engine to decouple the SharePoint framework from the version of TypeScript that's used, that's been updated to 0.4.0 that's up from 0.2.2. And finally, the version of Webpack that's used to create these bundles, that's been updated to use 5.77.0. Now there's two changes to ESLint and they were not included in the release notes. One of them is explicitly setting the version of ESLint that's used by the SharePoint Framework projects in the Project Dev Dependencies section of its package.json file. Previously, the SharePoint Framework assumed or relied on the fact that underlying dependencies were including ESLint, but that meant that the SharePoint Framework was not controlling the version that was used and meant something else was controlling it. For example, in the previous version of the SharePoint Framework, like 1.16.1, your project was using ESLint 8.30, which came from some underlying dependency, but now it explicitly is set to 8.7. Now I wonder what caused them to do that? Someone must have run into something. Oh well, it really doesn't matter at this point. This is a better way of doing it anyway. You wanna set your dependencies that you rely on to specific versions. You don't wanna always assume what somebody else is doing. Now another change that I noticed was a rule that was changed in the default ESLint rc.js file that's added to your projects. Previously, the rule TypeScript ESLint slash no parameter properties, that was set, but apparently that rule was deprecated in favor of one that doesn't have the no in it. It's now called TypeScript ESLint slash parameter properties. That was deprecated by the TypeScript or the ESLint team recently. So the SharePoint Framework team, they just updated it to use the correct term. Whew, I think we're done now. It's everything that I found in the 1.17 release. At least for now, we hope we don't have any kind of breaking changes coming out soon. There's quite a few changes, don't you think? To recap, while Microsoft included about 11 of these 20 things that I just ran through in their release notes, the other ones that they came from me picking through the code base in the release notes to show you everything that changed. What do you think about the updates that I've covered in this SharePoint Framework release? Do you see them as a positive move or are you disappointed by how small of a bump it was? Are you interested in seeing how I go through and do this deep research and figure out what the difference is between each one? Do you find value in this kind of in-depth review beyond what you get from the release notes? It takes a lot of work for me to do this. So I wanna make sure that it's worthwhile for me to keep making these videos. So please let me know if you appreciate it, if it actually helps you by leaving a comment below the video and make sure you like it as well. And if you like this video, please give me a thumbs up and subscribe to my channel by smashing that red subscribe button below the video so you'll see when I publish more videos for web and cloud developers on Microsoft 365, Microsoft Azure, and including topics like this on the SharePoint Framework. And lastly, if you want the latest news and insights delivered straight to your email inbox, join the 10,000 plus fellow web and cloud developers who subscribe to my newsletter that's linked in the description of the video below. I'm Andrew Connell, thanks for watching and I hope to see you next time.