CategoryPnP

Quick Tip: Importing React In SPFx Web Parts

We’re used to importing React into our web parts using this syntax:

import * as React from "react";

But did you know we can also do it using this syntax:

import React from "react";

How’s that possible? Let us talk about the difference first.

import something from “library-name”; is used to import the default export from that library. A “default export” is that thing that is marked as “default” when exporting code from a module. For example, you might see in a module file an export that looks like this:

export default MyClass;

Now when importing it, you can do it with import myclass from ‘MyClassModule’; Basically, the import something from “lib-name”; is a short hand for this:

import {default as something} from "lib-name";

As long as there is a default export, you can use import something from ‘lib-name’;

Now how about the other syntax (import * as something from “lib-name”)?

This is written when the library does not have a default export, but rather exports multiple objects together; for example, you might have the export looking like this:

export { something1, something2, something3}

See? No default export there.. so you you will need to import all (*) from that module. Which is the case with React.. If you go to React’s source code on Github: react/index.js at main · facebook/react · GitHub you will notice that they do not have export default in their file. But.. why can we do it in SPFx web parts?

The reason is, starting with TypeScript 2.7, there is a property in the tsconfig file that allows the compiler to analyze the exported package and treat the whole package as a default export, so you do not have to write the longer syntax (export * as), this property is called allowSyntheticDefaultImports, and as long as it is set to true, it will allow you to do that!

tsconfig.json

Demo – How to easily create web parts with SPFx and PnP JS

My demo at the Microsoft 365 Community Call is now published. It’s about how to easily create fancy web parts with SPFx and PnP JS.

Here’s the demo:

Working with XML & PnP Provisioning

If you work with PnP Provisioning Engine that much, you might reach a point where you want to have your configuration sitting in an XML file, and read its settings and pass it to your provisioning engine. However, you might run into some issues when dealing with special characters if you try for example to name your sites something such as “R&D”.

We’ll have a look at a case. Let’s say you have an XML configuration file named config.xml, that contains some settings regarding site urls and site names that you want to use in your provisioning engine. One of the values in XML might look like this:

Config.XML

If you try to read its value like this:

Reading XML file with PowerShell

You’ll end up with such an error:

Cannot convert value “System.Object[]” to type “System.Xml.XmlDocument”. Error: “‘<‘ is an unexpected token. The expected token is ‘;’

This means, that we’ll need to encode our value in XML, so we’ll end up with something like this:

Encoding values in XML

Or we can keep the value is XML as R&D, and replace the & with &amp; in our PowerShell script like the following:

Getting XML as string then replacing invalid characters


Now when we get the right value from $Config in PowerShell, it works just fine, and we’ll have a string as “R&D”. However, when we pass this value to our provisioning template:

It will complain again with such an error:

‘ ‘ is an unexpected token. The expected token is ‘;’.

The reason is, when it’s passed from PowerShell as “R&D” to the provisioning engine, it has to be encoded one more time. To do so, we’ll need to execute this before passing our values to the provisioning engine:

[System.Web.HttpUtility]::HtmlEncode($config.parameters.SiteTitle)

We store this in a variable, and pass it as a parameter to our provisioning engine. It will work like a charm!