TagMicrosoft365

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

Creating Organization Events Centre

white printer paperr
Photo Credits: https://unsplash.com/@erothermel

Holding events is a crucial task for any environment to keep employees up to date with everything taking place in the firm, however what do we do when we have too many departments, each having its own set of events? In this case an events centre to consolidate events is a good way to think about it, and this is what we did at BDO Canada!

Many companies like BDO have many departments, from Taxes, BDO Law, Industries, Digital office .. to IT, Marketing and Human Resources.. just to name a few! Each department has its own events going on and each department is its own hub site with more associated sites connected to it.

Our plan was to create yet one more site, name it Events Centre as part of the Intranet Home hub site that will show events across ONLY hub sites. For example, we have an Industries hub site, “under” that industry site we have associated sites such as Agriculture, Cannabis, etc..

You can use an Events web part on the Industries site to show events across the hub itself, this is a setting that’s available on the Events web part to show events across all sites in the hub:

Now what we want to appear on the events centre is a rollout of all “Intranet” events. To do that we created a content type specific for “Intranet Events”. To have that, we’ll need to create a content type inheriting from the basic Event content type and add it to each Events list and make it the default content type. On top of that, we want to have our own categories, because the categories that exist by default in the Events list don’t match our needs. So to achieve this, we used PnP Provisioning Templates in combination with PnP PowerShell.

PnP Templates will provision everything to the department sites once they are created such as any required site columns, content types, modifications to lists/libraries such as adding content types to these libraries, adding the custom event content type to the events list and making it the default, adding page templates, pages and so on.

The PnP PowerShell will do extra work such as changing the category column values (plus other extra stuff we needed it to do). Now we have a consistent structure for all departments created and all of them have the same content type. Back to our Events centre, we can place an Events web part for each category filtered by that categories name.

In fact we can use the category right without having to create a custom content type, but if you want to make your events scalable for later (for example, get all “Intranet” events in Search) then having your own events content type is very handy.

The end result of this would look like:

One catch is when you filter a category that contains a character such as “-“, you’ll need to replace the – with a space. For example, “Firm-wide” category will be filtered as “Firm wide”.

Notice that the categories don’t represent departments. They are shared across all departments in the environment. With the help of PnP Provisioning templates and PnP PowerShell Scripts we are able to keep this consistency across all departments.

Hope this would inspire you on the possibilities of things you can achieve with such a simple web part like the Events web part.

Feel free to reach out if you need to implement a similar functionality in your environment or if you have any questions, It’d be my pleasure to discuss it with you!