SharePoint Framework v1.2 - What's in the latest update of SPFx?

Last week was a busy week for the SharePoint Framework guys as we saw two big milestones and a bit of a scramble. We saw a new drop that changed the project scaffolding a bit, some new or updated support and a new drop for an upcoming feature. In this post, I’ll summarize all these things and point out a few things Microsoft has yet to explain in depth yet.

SPFx Extensions Release Candidate (RC0)

As we expected, Microsoft pushed a release candidate version, dubbed RC0, for the SharePoint Framework Extensions. There were a few subtle API changes as we expected, but nothing major and things that can be easily addressed. The changes include things such as:

• changing the placeholders Application Customizers have access to from PageHeader & PageFooter to Top & Bottom
• instead of using event.cellDiv in Field Customizers, you should use event.domElement which is consistent with web parts
• instead of using onRefreshCommand() to handle when Command Set buttons should change, you handle the onListViewUpdated() event

In addition to these API changes above, you can now play with SPFx Extensions in first release tenants which open them up whereas before they were only available developer tenants acquired as part of the Office 365 developer program.

A new capability snuck into this RC out of the blue: Application Events. With these, you can attach to an application-wide event within your component. What you do is attach (or remove) an event listener to either the application object or placeholderProvider object (in the case of Application Customizers). With that you can then handle navigation events (in the case of the application object) or changed events (in the case of the placeholderProvider object). There aren’t many details on this in the release notes, but one to keep an eye on.

A list of dev preview to release candidate changes can be found on the official docs site: Changes between Dev Preview and Release Candidate for SharePoint Framework Extensions (preview).

SPFx v1.2 + Updated Yeoman Generator

This was a more significant change if you ask me. As part of the Extensions RC0 update, Redmond also pushed a new Yeoman Generator. You can update your generator by running the following command:

npm install @microsoft/generator-sharepoint -g

Not only does this include the changes from Extensions RC0, but it also includes the following:

• support for TypeScript 2.4
• support for React 15 typings (type definitions)

New Bundling Schema

One change to your project types you might notice when creating a new project scaffolding with the new generator is in the config.json file… specifically the entries node. Prior to v1.2, each SPFx solution could only create a single bundle for each component. This was done using a syntax like the following:

{
  "entries": [
    {
      "entry": "./lib/webparts/webPart1/MyWebPart1.js",
      "manifest": "./src/webparts/webPart1/MyWebPart1.manifest.json",
      "outputPath": "./dist/my-web-part-1.bundle.js"
    }
  ],
  "externals": {},
  "localizedResources": {}
}

However in SPFx v1.2, Microsoft has deprecated the entries node and replaced it with the bundles node. This is going to allow us to create multiple bundles from a single SPFx solution and put one or more components into specific bundles. The new syntax looks like this:

{
  "$schema": "https://dev.office.com/json-schemas/spfx-build/config.2.0.schema.json",
  "version": "2.0",
  "bundles": {
    "my-web-part-1": {
      "components": [
        {
          "entrypoint": "./lib/extensions/webPart1/MyWebPart1.js",
          "manifest": "./src/extensions/webPart1/MyWebPart1.manifest.json"
        }
      ]
    }
  },
  "externals": { },
  "localizedResources": { }
}

This gives us a good bit more options when it comes to packaging up for deployment the things we create!

JSON Schema Definitions

Maybe it’s just me, but I get annoyed when I’m in a configuration file in an SPFx project and have all these validation errors going on and/or poor IntelliSense. Well, the team finally resolved that. If you look at the top of the config files, you will now see a $schema entry that points to a URL (look at the last snippet I posted above for reference). Previously these pointed to incorrect references nested down in the node_modules folder. What a nice improvement!

Other Bug Fixes & Updates

You’ll also find numerous updates and bug fixes listed in the release notes on GitHub for this release: Release Notes Extensions RC Drop 1.2.

As you know, I’m working on a SharePoint Framework developer course that I will pre-release very soon. I’ll blog more about the details on that later this week. In building a developer course, you frequently peel back the onion to see how things work and sometimes, you find things that others might have missed. It’s nice to see some of the things I found get addressed in the release notes, such as:

• Added aria support to all the controls Github issue #763
• Fix the logic to apply web part minimum height Github issue #696
• Add aria label property to drop-down control Github issue #763
• Add onAriaLabel and offAriaLabel in IPropertyPaneToggle Github issue #763
• Improve the generator so it does not append the component type to the class name if it already is included in the component name. Automatically truncate alias if it is more than 40 characters in length. Github issue #706
• Remove the .npmignore and .gitattributes from the solution template. Github issue #653

Not All Roses

Unfortunately, this rollout hasn’t gone without issues. Many people ran into issues when they tried to restore projects built with an older generator. Most of the issues seemed to come from those who had version 1.0.2 installed which was released in early April 2017. Microsoft had to republish a package that was no longer available in order to fix this.

One good thing did come out of that issue though is that Microsoft did confirm that going forward, the team was going to work to lock down the versions of packages they depend on (see this comment). This will go a long way to addressing challenges we have run into multiple times in the past… kudos!

Although, I’ve noticed some not so great stuff with the latest update though and a few others I’ve asked are seeing the same things. The new local workbench is MUCH SLOWER and MUCH FATTER than before. I’m noticing broken images, very slow responsiveness and overall a regression in the performance. Are you seeing it too? Make sure you chime in and add a +1 or your thoughts on this issue I’ve spun up: #824 - Local workbench from generator v1.2 is a LOT slower than prior versions

And if you’re like me, you’re still waiting on more placeholders you can target as well as local workbench support for extensions. Let’s keep up the pressure and make our voices heard! Vote these up on UserVoice and +1 them on GitHub!

• Give me more placeholders! UserVoice & Github #625
• Give me support for extensions in the local workbench! UserVoice & Github #691

August 31, 2017 SPFx + JavaScript SIG Meeting

A lot of this stuff, and more, is covered in the latest SIG meeting which was recorded and available here:

But Wait, There’s More!

I’ve got a little surprise for you to developers out there. Have you noticed when you look at the browser console, there is an absurd number of log entries that show up? Even in the local workbench, there’s a crazy number of entries coming from a file beacon.js? No? Launch the local SPFx workbench, open the console and wait… boom… you’re flooded!

While you can tell it to stop logging to the console by entering window.disableBeaconLogToConsole = true; on each session, it would be nice to kill it all together right?

Well, in asking around, apparently that file is coming from something the SPFx guys depend on from the OneDrive guys and it’s only used for internal stuff. It was never supposed to be enabled or released! In a future release not only will you see beacon.js go away but the team is committed to cutting down the logging in the console so it won’t get in our way. Yeah!