Join us at SharePoint Saturday Detroit on December 2nd!

Matt Jimison and I will be presenting Getting Started with the SharePoint Framework (SPFx) on Saturday, December 2nd, 2017 in Detroit as part of SharePoint Saturday Detroit!

Our session is at 1:30 and will introduce you to the SharePoint Framework (both web parts and extensions). We’ll actually walk you through getting the various tools installed and ready (bring your laptop) so that by the time you leave you’ll know not only what the SharePoint Framework is, what it can do, and when to use it – you’ll be ready to start experimenting immediately!

A Verbose Schema for SharePoint Column Formatting (Proposal)

Declarative customization through Column Formatting in SharePoint Online is a really cool new way to customize how fields in lists and libraries are displayed. It’s all done through JSON and it’s pretty awesome.

I think there are a few minor areas it’s currently falling short, however. Such as:

Unfortunately, although there is an open source repo of great samples, Column Formatting itself is not something we can directly contribute to (outside of issues and user voice like the above). But, I had another issue that I really wanted solved so I solved it (at least for me) and thought I’d share and suggest it (or some version of it) should be adopted officially.

While a UI for generating the JSON would be awesome, the alternative suggestion of writing your column formatter in VS Code using the schema.json is a good one. However, I really wanted better intellisense to help me track down what I can and can’t do. So, I added a bunch of stuff to the schema.json file to do exactly that.

A Verbose Schema

Using my version of the columnFormattingSchema.json (currently available as a gist), you get fancy stuff like this:

VerboseColumnFormatting

Here’s what’s in here compared to the original:

  • Valid operations toLocalString(), toLocaleDateString(), and toLocaleTimeString() are no longer marked as invalid (added them to the operator enum)
  • The style property now only allows values corresponding to supported style attributes
    • Additionally, each style property has enum values corresponding to possible values
  • Valid attributes iconName, rel, and title are no longer marked as invalid
  • class attribute provides enum values (using the predefined classes)
  • target attribute provides enum values
  • role attribute provides enum values
  • rel attribute provides enum values
  • iconName attribute provides enum values
  • Most properties (like txtContent and operators) provide special string enums (@currentField, @me, @now, etc.)

It’s important to note that every value can still be an expression and even where enums are provided for convenience (like class or txtContent), you can still supply a string not in the list.

Using the Schema

When you apply column formatting the JSON is validated, but the actual schema isn’t really restricted like you might expect (this is why you could previously specify an iconName property without issue even though it was technically invalid). This also means that using the Verbose schema won’t cause any problems for you (I’ve actually tested it against every sample available to me) and is actually much more likely to prevent you from getting multiple console error messages about unsupported style attributes, etc.

For now, you can just save the file to your machine and use a local reference (as shown in the image above) or, even better, you can reference it directly from the gist (raw) like this:

{
    "$schema": "https://gist.githubusercontent.com/thechriskent/2e09be14a4b491cfae256220cfca6310/raw/eb9f675bf523208eb840c462d4f716fa92ce14c2/columnFormattingSchema.json"
}

Now, as long as you save that file with a .json extension, VS Code will automatically add the intellisense and extra validation!

You don’t even need to remove the $schema property (you can even leave it out, it is not currently used by SharePoint at all).

Also, for anyone that is wondering what the column formatter shown in the animation above looks like, here it is for a Person field:

Final
My name is red since I’m the logged in user

Utilizing SPFx serveConfigurations

Recently a new serveConfigurations section was added to the serve.json config file in new SPFx Extension projects. These are a huge help when it comes to debugging extensions and are especially helpful when testing ClientSideProperties.

Robot-Tennis--33121

Background

Prior to the introduction of serveConfigurations, you couldn’t just run the gulp serve command like you do for webparts since that launches the local workbench where extensions couldn’t (and still can’t) be tested.

So the advice was to use gulp serve –nobrowser and then just navigate manually to a page in O365 and paste an ugly (and easy to screw up) set of querystrings.

Waldek Mastykarz even created a gulp task, gulp serve-info, that made this a little easier. I used it in my extensions and it was a huge leg up, but the whole thing was still clunky and a significant complexity preventing new developers from getting into extension development (or at least frustrating them).

What was needed was something as simple as gulp serve that took into account your custom locations and unique property settings. Fortunately, that’s where serveConfigurations comes in!

Setting up your serveConfigurations

When you generate a new SPFx Extension you’ll find a couple of initial serveConfiguration entries were created for you automatically in the config/serve.json file:

Default serveConfigurations

The values of these configurations should remind you of all of those querystring parameters because that’s exactly how these are going to be used. These values will build the URL for you when you serve your solution. The IDs and properties all match what was generated (although you are unlikely to keep the testMessage property for long).

The first thing you should do is replace the pageUrl property with the page address in your O365 tenant where you want to test the extension. Keep in mind these values are NOT used in the final package and are only for testing.

The sample above is for an Application Customizer (which is why the location property exists). Each type of extension will have slightly different properties (same as the debug querystrings), but will be added for you with your extension.

Multiple serveConfigurations

If you’re only doing a single extension in your solution and you aren’t using ClientSideProperties then all you need is the default entry using your own pageUrl value. If however, you have multiple extensions, then you’ll want an entry for each so that you can selectively decide which one you are serving when running gulp serve.

It is also comes in handy when you want to test different ClientSideProperty configurations. For my Field Customizer sample SPFx Item Order I allowed users to specify an OrderField property. When it was present the extension did one thing and when it wasn’t it did another.

To make this easy I included 2 serveConfigurations entries (one with the property and one without):

custom serveConfigurations

Using the serveConfigurations

Text in a json file! WOW! But how does this help?

Now when you run gulp serve the default serveConfiguration entry will be used and the browser will go to the pageUrl you specified and the debug querystring will be built using the values you provided!

Even better, you can specify which serveConfiguration you want to use using the –config parameter. So for the Item Order Field Customizer shown above, I could test the custom field configuration by entering this at a command prompt:

gulp serve --config=customField

Now the browser will be launched and my custom property will be set!

You can even see the URL that the browser will be sent to directly in the command output:

GeneratedURL

Aren’t you glad you didn’t have to type that (and get it right)? So, if you’re doing SPFx Extension development, serveConfigurations makes your life much easier!

The PnP Super Hero we “Need”

The SharePoint Patterns and Practices group often features a super hero clip-art with PnP on his chest. I really like the superhero (I’ve even got him as a sticker on my laptop), but there are several things about him that have been driving me nuts for a long time:

Original Issues

The biggest issue was that the only copy I have is a raster image which means it looks blocky when I make it bigger. So I remade the PnP Man in Inkscape as an SVG Vector image:

PnPmanOriginal600
Shown here as a png

 

I couldn’t resist fixing the armpit issue. However, I also felt the need to make additional updates so I ended up with this Updated Vector:

PnPman600
Also a png

I adjusted some of the curves, gave him a neck, adjusted the colors, and attached his cape at the shoulders. If you’re interested in using these images, you can find them on GitHub: github.com/thechriskent/PnPMan

PnPManComparison

You can use the SVG image directly in Office programs like PowerPoint and it will keep the scaling values for you and even treat it like a graphics object instead of a picture. There are also generated png files in several sizes available for other programs as needed.

Of course, you can also edit the SVG file directly where you’ll find everything is in layers so you can easily adjust the colors (including skin color), turn off or swap out elements (like the PnP logo), or adapt it to different versions (like a heroine or Stranger Things characters). Feel free to submit a pull request!

These files can be freely used for anything (PnP related or not) with no attribution required. You can also completely ignore this and keep using the old one. This is probably my weirdest and most unasked for “contribution” to SharePoint PnP yet!