Monday, 22 August 2016

Making a POST request to SharePoint from an SPFx webpart

Following up on my previous post First SPFx webpart: Get/Set a single value userprofile property in SharePoint, in this post I have separately documented how to make an HTTP POST request from your SPFx webpart. There are lots of posts out already which show you how to make a GET request so I will not cover that here. It is fairly straightforward once you understand all the moving parts.

Some notes around this:

1) The SharePoint Framework (SPFx) is in Developer Preview now so any/all the content of this post is subject to change (although I hope it doesn't)

2) SPFx webparts are not meant for production use at this time.

3) In this sample, I am making a HTTP POST request to SharePoint to create a list.

4) There is a feature/bug in SPFx right now where it adds the odata-version:4 header to every request that does not have the odata header declared. This causes calls to the SharePoint REST API to return malformed responses as it only supports Odata V3 at this time.

So the workaround right now is to explicitly add the odata-version:3 header to every request as shown in the following code.

5) All the code I have shown here is in TypeScript version 1.8.9 as currently dictated by the SharePoint Framework.

Without much further ado, here is the code:

Declare an interface which will be used in the code. This will need to be outside your webpart class.

Now, the code which makes a POST request to create a list:

And my "Developer workbench" list is created:

Hope this helps.

Sunday, 21 August 2016

First SPFx webpart: Get/Set a single value userprofile property in SharePoint

So the Developer preview of the SharePoint Framework was released last week and I decided to get my hands dirty right away. This is a webpart I created just to get a hang of things and to learn the key concepts of the SharePoint Framework.

The code is on GitHub:

Since I had not worked with React a lot, I decided to choose it as my JS framework.

Things I managed to wrap my head around while creating this simple webpart:

1) How to create a SPFx webpart with React as the JS framework.

2) How to talk to SharePoint from within the SPFx webpart with context.httpClient.get and

4) Creating reactive as well as non reactive webpart properties

5) The new _spClientSidePageContext object which contains heaps of context data. According to the wiki, properties of this object will be deprecated and moved under the Context object of the webpart.

(For now, I had to manually create an ambient declaration for this object but hopefully soon, the need for this will go away as it will be moved in the Context object)

6) Office UI Fabric and React Components for Office UI fabric

Since lots of these things were new to me, you might find some bugs/mistakes/horrors in the code so apologies for that in advance. Don't forget to leave a comment and I will be happy to update my code.


Sunday, 14 August 2016

Upload changed display templates to SharePoint using Gulp

Here is a quick tip which might be helpful when working with display templates. A typical SharePoint solution can have a large number of display templates but while working with them, you might me modifying/customizing only one at a time. Here is a quick gulp task I have put together which watches for changes in the HTML file of the display template and uploads only the changed display templates to the Master Page gallery.

Then I just start the watch task and change/save a display template:

Whenever I save an HTML file of my display template, it gets uploaded and checked-in in the Master Page Gallery. That causes a corresponding JS file to get generated automatically so I don't have to worry about managing it. 

If you are maintaining your Display Template JS files in source control, you will have to remember to copy the generated JS file back into your solution. 

Hope this helps you speed up your Display Template development. I have uploaded this project on GitHub here:

Thanks for reading!

Monday, 18 July 2016

Getting started with TypeScript, Browserify and Gulp in SharePoint

In my previous post Simple bundle, minify and upload JS to SharePoint using Gulp we saw how Gulp tasks can be used to simplify our JavaScript development experience in SharePoint. I am really impressed with Gulp as it has increased my productivity and I don't remember the last time I used SharePoint Designer :)

Now let's see how can we bring TypeScript into the mix. I have been playing around with TypeScript for a while now and here is my basic development workflow:

1) Create a main app.ts file which will contain the primary code for my application or "WebPart". In addition, app.ts will also have import references to any custom or third party modules e.g. jQuery

3) Use tslint to check the quality of my TypeScript

4) Use browserify and tsify to parse my TypeScript file and create a single JavaScript file (app.js) which includes all the dependencies required to run my app.

5) Minify my app.js using gulp-uglify and rename it to app.min.js using gulp-rename

6) Upload the debug and minified files to the Style Library in SharePoint using gulp-spsave

7) Then the JavaScript files can be used any way I like e.g. embed it using a Custom Action or in a Script Editor or a Content Editor WebPart.

Before we begin, if you are using Visual Studio 2015 like me, make sure you have the latest version of Node installed and Visual Studio is configured to use it. Here is an excellent tutorial on how to do this: How to configure Visual Studio 2015 with the latest version of Node.js and NPM

Now let us have a look at the important bits of my solution. I have uploaded the entire solution on GitHub here:

1) app.ts file:

At the top, the import statements are used to indicate that the code in this file is dependent on these modules. The first being jQuery and the second being my custom User module. Next, we simply create an object of the User class and call it's getDetails and displayDetails methods.

2) User.ts

There is a bit more going on in my User.ts class. Just like my app.ts, the first line indicates, with an import statement, that this file is dependent on the jQuery module. The getDetails function gets the AccountName, DisplayName and Email of the current user from the SharePoint REST API and stores them as properties of the current instance. The  displayDetails function logs the same properties (of the current instance) to the console.

3) package.json

Here is a list of all npm packages used in my solution. Notice the jQuery package, browserify and tsify use it to include jQuery in the final bundle as it is requested by my app.

4) gulpfile.js

And finally, here is my gulpfile.js which does all the heavy lifting:

5) Gulp tasks:

The watch-ts-upload-to-sp task looks for any changes in the .ts files (app.ts and User.ts). If any changes are noticed, it runs the upload-to-sp task.

The upload-to-sp task has dependencies chained up so that the tasks are run in the following order:

1) lint-ts to check the code quality of TypeScript
2) browserify to import all the required modules and create a single app.js bundle file
3) minify-js to create a minified file.
4) Finally, the upload-to-sp task runs to upload the app.js and app.min.js files to the Style Library.

(click to zoom)

A note on Typings:

TypeScript uses TypeScript definition '.d.ts' files to provide intellisense while writing a file. The TypeScript Definition Manager "Typings" is the current recommended approach of including definition files in your project:

I have included typings as an NPM package in my solution (have a look my package.json file) and then used the following commands to get the required typings in my project:

Thanks for reading!

Friday, 17 June 2016

SharePoint Online: Write User Profile Properties with REST API

In my previous posts, we saw how to Set user profile properties using JSOM & JavaScript and Set another user's profile properties with CSOM

Now, here are some code snippets I have put together to set SharePoint User Profile properties with the SharePoint REST API

  • This code only works with SharePoint Online at this time.
  • Can be used to set single value as well as multi value user profile properties.
  • Can be used to set default (OOB) as well as custom user profile properties.

1) Set Single Value User Profile property with REST API:

2) Set Mutli Value User Profile property with REST API:

Hope you find this useful!

Wednesday, 1 June 2016

SharePoint Online: Get UserProfile Properties with REST API Batching

In my previous post SharePoint 2013: Get UserProfile Properties with REST APIwe saw how to fetch SharePoint UserProfile properties with the REST API.

The only thing missing in that post was, at the time there was no way to get Multiple UserProfile Properties for a Specific User i.e. if you had an account name of a user and wanted to fetch multiple custom or default UserProfile properties, you could not do that in a single REST call. You would have to resort to either making multiple REST calls using the GetUserProfilePropertyFor function, or you would have to use the JavaScript Client Object Model (JSOM)

When I wrote that post, SharePoint Online did not support REST API batching. Since then, it has been implemented and as a result we can get multiple Custom/OOB User Profile properties in a single REST call.

Here is my code showing how to do it:

Here are some other great resources on SharePoint REST API Batching:

Batch Processing (OData Version 3.0)

Part 1 - SharePoint REST API Batching - Understanding Batching Requests

Make batch requests with the REST APIs

Thanks for reading!

Tuesday, 31 May 2016

Identify Office 365 Tenants using a custom logo

I came across something really simple but equally useful recently.

It is quite well known that Office 365 allows you to set a custom image as a logo for your organisation. This logo then appears in the suite bar across the entire tenant.

When working on an Office 365 Development project, we have multiple tenants to take care of. Typically, they are  DEV, TEST, UAT and finally PROD.

When you are navigating between these tenants, a really simple way of telling them apart is to use a custom logo for each tenant!

We as developers might just quickly have a look at the URL to see which tenant we are in. But in many cases, the same tenants are used by non-technical members of the team who might need a clearer indication of which tenant they are in. This can also help in preventing someone accidentally doing something on the wrong tenant.

So here at Content and Code, we might have something like this:

Development Tenant:

Test Tenant:

UAT Tenant:

PROD does not require any special logo as that might confuse end users:

Here is how you set the custom theme and logo for your tenant:

Hope you find this useful!