OK, so if you haven't read JSON Column Formatting (Part 1), this entry will probably make less sense than it should. Take a minute and check that out before you go on with this blog post, and you will be much happier.

One important thing that has changed since Part 1 is that the schema of these JSON files is no longer found at: http://columnformatting.sharepointpnp.com/columnFormattingSchema.json

Instead, the schema can now be found at: https://developer.microsoft.com/json-schemas/sp/column-formatting.schema.json

Now that you are up to speed, let's dive in. If you reviewed the JSON formatting examples in the SharePoint/sp-dev-column-formatting github, you already have seen more impressive demonstrations of what can be done using JSON Column Formatting than we will be doing here.

In this post, we are going to take you through some examples that, while more advanced than Part 1, are as simple as we can make them to help teach some of the important concepts of this tool.

Let's start with an example you may find in other tutorials for JSON Column Formatting. This example that will be very handy in creating our "light" dashboards, changing the appearance of items based on a threshold:

{
"$schema": "https://developer.microsoft.com/json-schemas/sp/column-formatting.schema.json",
"elmType": "div",
"attributes": {
   "class": "=if(@currentField <= 10,'sp-field-severity--severeWarning', '')"
},
"children": [
   {
     "elmType": "span",
     "style": {
       "display": "inline-block",
       "padding": "0 4px"
     }
   },
   {
     "elmType": "span",
     "txtContent": "@currentField"
   }
]
}

With this formatting applied to a column that contains numbers, if the number is 10 or less, the field will have a reddish pink appearance, like this:

5119485e5c666f1b0a2d77c517233f2a.png

If the number is greater than 10, it will have no special formatting:

1b53dcca45546aa6976ddec10333ad0d.png

So, that looks pretty useful doesn't it? But if you read Part 1 you probably have some questions, because according to that I would have directly changed the color of the field to "background-color":"pink". instead of this odd "attributes": { "class": "=if(@currentField <= 10,'sp-field-severity--severeWarning', '')" }

So what is the difference? Well in Part 1, I added the formatting directly, and there is nothing wrong with that. But I also wanted to point out that we have a few other tools at our disposal. There are several built-in classes that we can use at any time for our formatting.

sp-field-severity--low (no color change)

Low

sp-field-severity--good

Good

sp-field-severity--warning

Warning

sp-field-severity--severeWarning

Servere Warning

sp-field-severity--blocked

Blocked

What is the advantage of these built-in classes? Consistency. If you use them anywhere within SharePoint, they will be the same. And if, in the future, Microsoft makes changes to these classes, your formatting will remain consistent with other places within SharePoint that use these classes to notify the users. You don't have to make sure you use the correct RGB value each time you format a field, you just use the level of notification you feel is appropriate. That said,

"attributes": { "class": "=if(@currentField <= 10,'sp-field-severity--severeWarning', '')" }

and

"style": { "background-color": "=if(@currentField <= 10,'rgba(234, 67, 0, .2)', '')" }

will look the same.

A quick note on style in JSON

The situations we are testing often consist of three parts: the condition; the result if true; and the result if false. These are called Ternary Operations.

In some programming languages you will see a ? or ?: replacing an "if" and the entire conditional statement spelled out differently. As a result, some developers will use that format when creating JSON.

In such a case, a format could be changed from:

{
"$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
"elmType": "div",
"attributes": {
   "class": ""
},
"style": {
"background-color": "=if(@currentField <= 10,'rgba(234, 67, 0, .2)', '')"
},
"txtContent": "@currentField"
}

"style": {
"background-color": "=if(@currentField <= 10,'rgba(234, 67, 0, .2)', '')"
},

would be replaced with:

"style": {
"background-color": {
         "operator": "?",
         "operands": [
           {
               "operator": "<=",
               "operands": [
                 "@currentField",10
             ]
           },
           "rgba(234, 67, 0, .2)",
           ""
         ]
     }
},

I personally prefer the more compact form, but if I were a real developer, I may prefer the more verbose form because it follows a pattern similar to a lot of programming languages. Just something to be aware of as you look through examples on the internet. Both forms work and are seen as valid JSON syntax, though as you begin to stack operations together (x <= (y+z) ) the verbose syntax, while more complex, may help you keep things straight.

There are other values that can help you keep things consistent in your project by pulling them from your theme. If you use those, then a change to your theme will automatically cause items to show the new theme colors. For a full listing of the values available, you can look at https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-theme-colors-in-your-customizations.

As an example, if you build JSON with those it looks like this:

ThemeColor1

If you change your theme from the current theme to Teal for example:

SwitchTheme

Your formatting will adjust automatically to use the new theme colors. It isn't 100% automatic; I did use a specific color for the font (white) so I may need to do a little adjusting. This isn't a remarkably interesting or exciting format, but if you are curious what it looks like, here is the finished version.

{
"$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
     "elmType": "div",
     "attributes": {
       "class": "ms-fontSize-xxl ms-fontWeight-regular ms-fontColor-white ms-borderColor-themePrimary ms-bgColor-themePrimary"
     },
     "style": {
       "font-family": "sans-serif"
     },
     "txtContent": "@currentField"
}

Little Lessons are Good Lessons

Again, these may not be the most exciting examples, but they are realistic. Using a value to change the appearance in a list is a particularly key step in using JSON formatting to provide the sort of lightweight dashboards we are targeting. Because I have been writing these at a slow pace, you can find some interesting uses for these things that have developed over time. If you look at Microsoft Lists, you can see this JSON formatting is something they have used as a basis for some "basic" lists they have created for our use. This formatting is one of the most flexible components within SharePoint Online that doesn't involve hardcore customization or the Power Platform. Put a little thought into what you can achieve, and if you come up with something spectacular, let us know so we can share it with the world!