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.
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:
event.cellDivin Field Customizers, you should use
event.domElementwhich is consistent with web parts
onRefreshCommand()to handle when Command Set buttons should change, you handle the
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).
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:
Not only does this include the changes from Extensions RC0, but it also includes the following:
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:
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:
This gives us a good bit more options when it comes to packaging up for deployment the things we create!
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!
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:
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!
A lot of this stuff, and more, is covered in the latest SIG meeting which was recorded and available here:
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!