Over the weekend I was able to attend and speak at the North American Collaboration Summit (Sharepointalooza) in Branson, Missouri. It was an extremely well run and attended event. It’s unbelievable to me that attendees were only paying $65 for content and experience that would cost $1500-2000+ elsewhere!
I spoke on Understanding SharePoint Patterns and Practices (PnP). I love this topic because it allows me to show off amazing stuff that always has immediate “Monday” value. People always leave this session with at least one or two things they’ll start using as soon as they get back to work. SharePoint PnP is awesome but it can be difficult to know about everything that is available.
I was able to demo:
SharePoint PnP PowerShell
Site Designs with Remote Provisioning
I even demonstrated how to do the simplest (but still very much appreciated) contribution by live fixing documentation!
Thanks to everyone who attended. I got a lot of great questions and once again people were really impressed with what PnP has to offer! Awesome event, awesome sponsors, awesome speakers, and awesome attendees!
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.
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: