Using Chrome dev tools to get SharePoint API calls in JSON

When working with Power Automate I wanted an easy way to get the JSON version of an API call.

When looking at a normal API link in a webpage you get XML

https://xomino.sharepoint.com/sites/SPFest2019/_api/web/lists/getbytitle('MarkyList')/items

To be able to see the output in JSON we can use Chrome Dev Tools to call the same page and pass in the apporpriate header to turn it into JSON

fetch(location.href, {
  method: 'GET',
  headers: {
    'Accept': "application/json;odata=verbose"
  }
})
.then(res => res.text())
.then(console.log)

And from this you can get the output quickly from the console

Removing commas from number fields in SharePoint online view items

In this article I will show (and reference) a neat piece of formatting code I found to change a year of 2020 from 2,020 to 2020 in a list view

The Problem

Simply put, if you have a number in a list in SharePoint it will add number formatting by default. A view with a Year number value of 2020 will display as 2,020

The solution

Using Colulumn formatting you can superceed the default formatting by replacing the value displayed in the field with a text value of the same thing

I found the solution on stackexchange – https://sharepoint.stackexchange.com/a/269817/48559

Select the option to format the column

Add the following into the formatting box (advanced mode)

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

And there you have it

Changing your SharePoint online root site to a communication site

In this article we will look at how to change the root site of your SharePoint online tenant.

Introduction

By default your SharePoint Online default site is unlikely to be the site you want users to go to.

Invoke-SPOSiteSwap

Using the Invoke-SPOSiteSwap command inside of the SharePoint Online Management Shell we are able ot change the root site.

Download and install the management shell

And then use your version of the following script to change your tenant root site. You will have to have admin access to the tenant to be able to do this

$targetSite = “https://yourTenant.sharepoint.com”
$soureSite = “https://yourTenant.sharepoint.com/sites/yourSite”
$archiveSite = “https://yourTenant.sharepoint.com/sites/archivedRoot”
Connect-SPOService -Url https://yourTenant-admin.sharepoint.com
Invoke-SPOSiteSwap -SourceUrl $soureSite -TargetUrl $targetSite -ArchiveUrl $archiveSite

Basic Introduction: Automatic Testing of SharePoint online using Cypress.io

In this article we will look at the Automated Testing tool Cypress.io and look at the basic requirements for being able to set it up to test against a SharePoint online list. There are some interesting nuances to look at but the basic pronciples hold true.

Introduction

Cypress.io is a front end automated testing tool which has been around for a couple of years but has received significant interest from the open source community. It is an electron based testing tool with significant advantages over using the long term front end testing defacto tool Selenium. There are some disadvantages as well (being Chrome only right now) but as modern web browers get closer and closer to parity, that is less of an issue than say 5 years ago. After talking to my react development friends at the Northwest JavaScript meetup I resolved to try and make it work.

There are other recommendations for automated testing including a great article from Elio Struyf which uses a combination of puppeteer and jest – but again I wanted to try Cypress.io. It was challenging !

Update: Sheer coincidence, Elio also published an article on Cypress today!

Authentication and SharePoint online

The Cypress.io engine is based on electron – which means it runs in node. This is very advantageous, in that it has the ability to use open source npm libraries as part of its run time. In this case it allowed me to use the node-sp-auth to be able to generate the necessary headers to access a SharePoint Online site as an authenticated user. For the sake of this example I had the username and password in the config – you probably want to look at encrypting that or soemthing 😉

Cypress tasks

Cypress.io has the ability to create custom tasks which will execute some node code. So I created a custom login capability using the node-sp-auth library. This code should be added to the index.js file in the root of the cypress code.

const spauth = require("node-sp-auth");

let getLogin = async () => {
  const username = "me@mydomain.org";
  const password = "********";
  const pageUrl = "https://mydomain.sharepoint.com/sites/HelloWorld";

  // Connect to SharePoint
  const data = await spauth.getAuth(pageUrl, {
    username: username,
    password: password
  });
  return data;
};

module.exports = (on, config) => {
  // `on` is used to hook into various events Cypress emits
  // `config` is the resolved Cypress config
  on("task", {
    // deconstruct the individual properties
    getLogin() {
      return getLogin();
    }
  });
};

 

Running the test

This code can then be referenced in the Cypress.io code to create the login headers necessary for authentication, before each of the tests are run. The waits are in here because I have to make sure the DOM is ready. It is a little clunky and I need to figure out how to do it better………

describe("Sample SharePoint List test", function() {
  beforeEach(() => {
    cy.task("getLogin").then(token => {
      cy.visit({
        method: "GET",
        url: "https://mydomain.sharepoint.com/sites/HelloWorld/Lists/CyList",
        headers: token.headers
      });
    });

    cy.wait(2000)
      .get(".od-TopBar-item")
      .wait(1000)
      .find('[name="New"]')
      .wait(1000)
      .click();
  });

  it("Should have a title of Hello World", function() {
    cy.title().should("contain", "Hello World");
  });

  it("Should have a validated Title value", function() {
    cy.get('[aria-label="New item form panel"]')
      .find(".od-TopBar-item")
      .wait(1000)
      .find('[name = "Save"]')
      .wait(1000)
      .click();
    cy.get('[data-automation-id="error-message"]').should(
      "contain",
      "You can't leave this blank."
    );
    cy.get('[aria-label="New item form panel"]')
      .find(".od-TopBar-item")
      .find('[name = "Cancel"]')
      .click();
  });

  it("Should submit the form with a minimum Title field", function() {
    cy.viewport(550, 750);
    cy.get(".ReactFieldEditor")
      .eq(0)
      .type("sample text");
    cy.get('[aria-label="New item form panel"]')
      .find(".od-TopBar-item")
      .find('[name = "Save"]')
      .click();
  });
});

Here’s how it looks

Running the test – we can see that cypress runs through each of the tests, waiting for the DOM to be ready…..(see below) and ultimately automated a Funcational test of the list. One of the REALLY cool things about Cypress is the ability to move back through the test and see what was executed at the time of the test. This allows the web developer to see the DOM state and everything, should their test fail!!

 

What I found about SharePoint

The modern SharePoint Framework, and more specifically the React JavaScript library on which it is based, uses Web Components to render the DOM. What this means is that the webpage itself renders aynchronously and at times under no control of my own, will re-renter itself as the page decides. This means that during the automated test, I came across multiple instances of where Cypress failed because the DOM elements were no longer attached. This is going to need some work on my part to figure this out……

Conclusion

You can use Cypress.io to functional test SharePoint online and SPFx – but there is clearly a lot more to learn 🙂

 

Fixing SPFx node-sass binding error on ADO release pipeline

When trying to run the gulp upload-to-sharepoint  encountered the following issue when creating a release pipeline for an SPFx web-part. There was a problem with no binding available for node-sass

[command]C:\NPM\Modules\gulp.cmd upload-to-sharepoint –gulpfile D:\a\r1\a\build\release\gulpfile.js –ship –username *** –password *** –tenant mckinseyandcompany –cdnsite sites/apps/ –cdnlib ClientSideAssets
2019-06-12T14:51:53.5954467Z [14:51:53] Working directory changed to D:\a\r1\a\build\release
2019-06-12T14:51:54.5490645Z D:\a\r1\a\build\release\node_modules\node-sass\lib\binding.js:15
2019-06-12T14:51:54.5497252Z throw new Error(errors.missingBinary());
2019-06-12T14:51:54.5498022Z ^
2019-06-12T14:51:54.5498662Z
2019-06-12T14:51:54.5499258Z Error: Missing binding D:\a\r1\a\build\release\node_modules\node-sass\vendor\win32-x64-48\binding.node
2019-06-12T14:51:54.5499538Z Node Sass could not find a binding for your current environment: Windows 64-bit with Node.js 6.x
2019-06-12T14:51:54.5499731Z
2019-06-12T14:51:54.5499883Z Found bindings for the following environments:
2019-06-12T14:51:54.5500034Z – Windows 64-bit with Node.js 8.x

and the error was actually staring us in the face – “binding available for Node 8″……..

The solution, just like for the build process, you have to add an agent task to ensure the correct version of node is used for the release process.

Using npm ci as part of the SPFx CI CD process through Azure Dev Ops

During the Automated Build and Deploy process for a SharePoint Framework Web Part (as documented here) one of the steps you go through to install the application on the build server is a familiar step ‘npm install’.

This works just fine when working locally and should be, but it is inefficient as part of an automated build process.

For a good explaination of why, check out this stackoverflow answer https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci/53325242#53325242

npm install reads package.json to create a list of dependencies and uses package-lock.json to inform which versions of these dependencies to install. If a dependency is not in package-lock.json it will be added by npm install.

npm ci (named after Continuous Integration) installs dependencies directly from package-lock.json and uses package.json only to validate that there are no mismatched versions. If any dependencies are missing or have incompatible versions, it will throw an error.

In my experience this can speed up the build process by more than 50% and as the npm install is the rate determining step for the overall buil, this is very helpful.

The step in the process for the build should look like this:

I have submitted a pull request to update the documentation and we will see if it is worthy 🙂

 

 

Correcting SPFx gulp –ship Uglify Errors: Unexpected token: punc (()

We came across the following problem when trying to execute a gulp --ship on out SPFx development


[15:03:34] Starting subtask 'webpack'...
[15:03:49] Error - [webpack] 'dist':
list-view-demo-webpart-web-part.js from UglifyJs
Unexpected token: punc (() [list-view-demo-webpart-web-part.js:962,7]

In researching this issue it turns out that this issue stems from a problem with the webpack uglify plugin (uglify-webpack-plugin) which historically does not work with ES6 code.

From what I read, it seems like the current SPFx 1.8 does use the correct version of webpack and the uglify plugin to avoid this issue but it was still coming up.

We solved the issue by implementing a suggestion to a related issue on github

https://github.com/SharePoint/sp-dev-docs/issues/2782

The key was presented in one of the responses to the issue

https://github.com/SharePoint/sp-dev-docs/issues/2782#issuecomment-475519680

By replacing the uglify plugin with the terser plugin for webpack, the issue was resolved and we were able to Build and deploy.

Speaking at SharePointFest Chicago 2018

I am very lucky enough to have been accepted to speak at SharePointFest Chicago for the third year running now. The subject is Automated Build and deploy of SharePoint Framework webparts.

One of the really fascinating things about working in a modern large development team is the outstanding benefits for automated testing, automated build, and automated deployment. Even for something which might not on the surface seem to be a “big deal” such as SPFx webpart development, has many advantages to be gained by using a professional automated development environment.

Since I submitted and was accepted to speak, VSTS has been renamed to Azure DevOps, so this might be difficult to pull off as a topic – but i think we will be ok 😉

SharePointFest is always  alot of fun with a good crowd of speakers and attendees. I am excited to attend and excited to speak 🙂

 

DEV304 – Using VSTS to automate build and deployment tasks for SharePoint Framework webparts

Working on your own and building SharePoint Framework webparts is one thing, but when you have to work in a team on a larger project, the team approach to development has to be more structured and automated.

Modern team web development practices demand the use of unit tests, load testing and automated build and deploy methodologies. Why should developing for the Sharepoint framework be any different?

In this presentation Mark will highlight the advantages to using VSTS to create and manage and continuous build and deploy process for working with the Sharepoint Framework. Come and see how modern team development techniques can be applied to SPFx.

S106A Fri 2:20 PM – 3:30 pm

SharePoint now accessible via the Microsoft Graph beta

Last week at Ignite it was announced that finally Microsoft was bringing O365 SharePoint access to the Microsoft graph as an API. This is a huge deal for those of us who want to use O365 as a platform and develop engaging applications for customers. In my case for Office Add-ins this is great because it reduced the number of OAuth hoops I have to jump through and manage to get the data I want.

Here is a link to the documentation: Working with SharePoint sites in Microsoft Graph and a quick example.

NOTE: this is beta and will change – this is purely a demonstration of what is possible today (Oct 2016) and not to be used as future reference.

Example

Using the graph explorer demo I am able to bring up content from my default SharePoint site very easily

https://graph.microsoft.io/en-us/graph-explorer#

Here is my copper site within my SharePoint tenant

sh1

and here it is referenced from the graph API

https://graph.microsoft.com/beta/sharepoint/sites/site-id

sh2

here is the API response of the lists
https://graph.microsoft.com/beta/sharepoint/sites/site-id/lists

sh3

and here is a reference to the documents in the Shared Documents folder

https://graph.microsoft.com/beta/sharepoint/sites/site-id/lists/list-id/items

sh4

How cool is that !!!!!