ROphelders.com

SharePoint, Office365, .NET and more

Show menu Hide menu

AuthorRuud Ophelders

Fixing IE11 Compatibility Problems in SPFx with Babel

October 30, 2019 / / 1 Comment

I recently ran into an annoying problem in one of my SPFx solutions; while it worked perfectly in Chrome, the Web Part didn’t even load in IE11. After a bit of digging, it turned out that the “SCRIPT1002” errors I was getting were caused by one of the npm packages I was using, which used the “class” keyword – a keyword introduced by ES6 but not supported by IE11. Worse still, while there are many polyfills for ES6 features, this is not possible for the “class” keyword.

The common solution to this kind of problem is to use a transpiler; a module that compiles existing code (even inside your node_modules folder) into JavaScript readable by older browsers. Babel-loader is a pretty well-known transpiler package that works with webpack – and here’s how you get it to work in your SPFx solution:

To use babel-loader in your SPFx solution, you first have to install it;

npm install -D babel-loader @babel/core @babel/preset-env webpack

Next, in your gulpfile.js, insert the following code just before the line that says build.initialze(gulp);

build.configureWebpack.mergeConfig({
  additionalConfiguration: (generatedConfiguration) => {
    generatedConfiguration.module.rules.push(
      {
        test: /\.m?js$/, use:
        {
          loader: "babel-loader",
          options:
          {
            presets: [["@babel/preset-env",
              {
                targets: {
                  "ie": "11"
                }
              }]]
          }
        }
      }
    );

    return generatedConfiguration;
  }
});

By doing this, you add an additional rule to your webpack configuration that tells the babel-loader to transpile your files into an IE11 compatible syntax.
Note that most default babel-loader configurations will add an “exclude” rule for the node_modules folder, but in this case we want Babel to transpile our npm packages since they were causing our problems.

Responsive SPFx Controls with Fabric UI React

November 15, 2018 / / 0 Comments

Have you ever built a control that you want to have behaving differently depending on whether you’re working on a mobile device or a desktop? For example, showing a callout when you’ve got a full resolution desktop screen available but using a screen covering panel on your mobile phone? Well, Fabric UI React continues to be a life saver and makes implementing this almost ridiculously easy with its ResponsiveMode utlility.

On a high resolution screen, the extension renders a Callout

On small screens, the extension uses a full-screen panel

The first thing you need to do is import the necessary interfaces and classes;

import { IWithResponsiveModeState, ResponsiveMode, withResponsiveMode } from 'office-ui-fabric-react/lib/utilities/decorators/withResponsiveMode';

Next, create an extension for your control’s Props interface to also implement IWithResponsiveModeState

export interface INavigationCalloutInternalProps extends INavigationCalloutProps, IWithResponsiveModeState { }

Finally, add the ‘@withResponsiveMode’ decorator to your class and make sure that your control uses the extended Props interface;

@withResponsiveMode
export class NavigationCallout extends React.Component<INavigationCalloutInternalProps, INavigationCalloutState> {

Now we’re all set to make our control change its behavior based on screen size. In our render() function, we can now do the following:

const isSmall = this.props.responsiveMode! &lt;= ResponsiveMode.medium;
{ isSmall ? (
      <Callout></Callout>
   ) : (
      <Panel></Panel>
   )
}

Staying Signed Into Multiple Office365 Tenants with Google Chrome Profiles

July 5, 2018 / / 0 Comments

As a SharePoint developer working with multiple customer tenants, I find myself logging in and out of different accounts continuously. At best I could use InPrivate windows to be signed into two different tenants at the same time but it’s always been a massive annoyance. Last month though at the European Collaboration Summit (great convention, by the way) I attended a Microsoft Q&A session and the answer to the question “Why do even the speakers from Microsoft use Chrome instead of Edge in their demos?” changed my life. The big secret is that Google Chrome allows you to create user profiles which have their own isolated browser sessions (thanks @vesajuvonen).

Setting it up is as simple as going into the browser settings and clicking on ‘Manage Other People’. You can then start different browser instances for each different tenant you have to log into; you can finally stay logged into your own company’s intranet while also working on a client’s SharePoint sites. These different browser instances also have their own sessions and cookies so if you opt to ‘stay signed in’, you won’t have to log in as often on that profile.

It’s a simple trick but if you’ve ever had to work with multiple different O365 tenants, you know how much of a time saver it can be.

The Mystery of the Empty Search Result Fields

April 16, 2018 / / 0 Comments

Today my colleague Roel and I ran into a problem that had us baffled. To set the scene; we were migrating a news aggregation platform to Office 365 consisting of multiple site collections that aggregate news from each other based on SharePoint Search. Each of these site collections is practically identical but strangely enough on some of them the search index was returning one specific field as empty even after multiple re-indexings.

To fast-forward through a few hours of utter frustration; at one point we remembered that we had practically the same problem before but on an on-premise SharePoint environment. The solution back then was to modify the SourceID in the SchemaXML of the field. The SourceID is a property that defines where a field originates (e.g. if it is a built-in field or a site column). Below is an example of what you might find in your field’s SchemaXML:

<Field 
   Type="Note" 
   DisplayName="MainText"
   [...] 
   SourceID="{a5a7f91f-b3c6-40e1-ab3d-0499544b8f52}" 
/>

The GUID in this example can refer to either a List ID or a Web ID – and as we found out this makes all the difference. On the sites where the field was being indexed, the SourceID referred to the Web ID and on the sites where the field remained empty the field referred to the List ID. While it’s not at all clear where this ID is used in SharePoint Search (or if it’s even used at all), I suspect that if the field is a site column, the SourceID must always refer to the Web ID instead of the List ID.

After we changed the SchemaXML of the faulty fields and scheduled a re-index of the List the contents were finally being indexed again and we sighed a collective breath of relief.

Working with SPFx projects in Visual Studio 2017 (or: how to avoid Visual Studio Code)

April 5, 2018 / / 0 Comments

I like the SharePoint Framework. It’s new, it’s fast and it’s miles ahead of what we’ve had before. I even like Node.js, NPM, Yeoman and the rest of the development ecosystem that comes with it. What I don’t like though, is Microsoft’s insistence that I should use Visual Studio Code. Even the name bothers me – Visual Studio Code – what the hell, Microsoft; what did you think I was using your previous versions of Visual Studio for? Novels? Why can’t I stick to good old Visual Studio 2017 with its plethora of features and extensions?

It’s still possible to keep working in Visual Studio 2017 of course, although you won’t have the comfort of Project Templates to help you along. My solution is as follows:

  • Create an empty Class Library Project
  • Open a command window to the path of the project (not the solution)
  • Run the SPFx Yeoman Generator (yo @microsoft/sharepoint)
  • Keep working in Visual Studio 2017 stubbornly

Note: Visual Studio 2017 has some issues with React so don’t expect to be able to rely on IntelliSense to show you where the errors in your code are. I’ll update this post if I ever find a solution to this, but for the time being I’m just happy to be able to work in the IDE of my choice.

Running the project

Wouldn’t it be nice though if pressing F5 would automatically execute a ‘gulp serve’ command? Well; that’s easy to set up too.

In the Properties of your project, navigate to the Debug tab and set the Launch property to ‘Executable’.

Next, enter ‘cmd’ as your executable.

Finally, set the Application arguments to

/K gulp serve

This will tell Visual Studio to open a command window and execute gulp serve when the project is started.

The Visual Studio Project Template

Wouldn’t it be nice though if there was a pre-made Visual Studio Project template and you didn’t have to  go through all these steps to run your SPFx project? Well, there is – kind of. The SPFx Project Template Extension – which basically runs the steps outlined in this blog post but automated in the form of a project template – is very promising but doesn’t seem to be actively maintained and only works for webparts, not extensions. As such, for the time being I can’t really recommend it, but it’s a good initiative to retain the ease-of-use found in Visual Studio 2017  for SPFx projects.

Upgrading SPFx 1.0 React WebParts

March 19, 2018 / / 0 Comments

When the SharePoint Framework first came out I spent a good amount of time porting over ‘old’ webparts to the new Modern standard. When someone discovered a bug in one of these SPFx 1.0 apps some time ago it was the perfect occasion to upgrade these to 1.4.1, especially since it is now possible to embed all client side content (images, javascript) inside the app itself, making the process of putting the scripts onto a CDN no longer necessary. What I quickly discovered though is that this isn’t as easy as just updating a few packages in NPM. To spare you the trouble of having to find this out for yourself, follow this guide to easily update your webparts.

Step 0: How not to update

At first I thought that updating would be as simple as just using NPM to update each individual package. This turned out to be the wrong choice, since package updates are not the only thing that has changed since the first release of SPFx and it doesn’t always necessarily use the latest version of 3rd party packages.

There’s a (relatively) easy way though; let the Yeoman scaffold tell you which packages to use. The steps below will guide you through the process of getting the latest generator and checking which changes you need to make to your existing project.

Step 1: Updating Yeoman and the SharePoint Generator

First of all we’ll update both Yeoman and the SPFx generator. Use the following commands in a command console window:

npm install yo@latest -g
npm install @microsoft/generator-sharepoint@latest -g

Step 2: Generate a new webpart

Navigate the command console to a temp folder and use Yeoman to generate a new app scaffold:

yo @microsoft/sharepoint

When Yeoman asks you what type of component you want to create, choose the same type as the app you’re going to upgrade.

Step 3: Copy the packages.json content

Now that Yeoman has generated a new app scaffold, we can open its package.json file to see exactly which packages/versions are currently required for the latest version of SPFx.

Next, find the package.json file in the project you’re trying to upgrade and make sure that the packages and versions under dependencies and devDependencies match. In my case I just shamelessly copy/pasted the entire file content (make sure you change the name afterwards) but if you added any additional packages which are not part of SPFx by default you might have to be a bit more careful.
Once you’ve updated your file, open a command window to the project you’re updating and use the following commands;

gulp clean

The command above cleans up the SharePoint build folders.

npm install

Next, tell NPM to install your packages, which it will do according to your new packages.json.

gulp build

Now we’ll attempt to build the webpart. You might be disappointed to learn that you’re still getting errors – but this leads us to the next step…

Step 4: Fix errors

Even though you’ve updated all your packages, you’ll probably still be getting plenty of errors in your build. This is the trickiest step, since what you’ll have to do to fix them is heavily dependent on your coding style and the changes that have been in the latest SPFx packages. So the changes that I had to make might not be the same for you, but I’ll at least share some pitfalls I’ve encountered to spare you the same troubles.

React Components

One of the build breaking changes in React is that when extending Components, you can no longer use void as the parameter for the component state. In my original webpart there were a lot of components defined like this:

export class Filter extends React.Component<IFilterProps, void> {

…which should be changed to:

export class Filter extends React.Component<IFilterProps, {}> {
Node_modules Folder

If your code still doesn’t build and you’re pulling out your hair in frustration, there might be some old files lingering in your node_modules folder. Try deleting the node_modules folder for your project and running npm install again.

Step 5: Success!

If your code builds again, congratulations! If not, I hope that I’ve at least managed to get you a few steps ahead. For me, the steps above were enough to update my SPFx 1.0 webpart to 1.4.1, but of course I can’t guarantee that the same will be true for everyone.

© 2019 ROphelders.com

Theme by Anders Norén — Up ↑