Building SharePoint client web part with Vue.js and single-file components

Vue.js becomes more and more popular and it’s time to build real life sample using Vue’s single-file components. Single-files components are the building blocks for Vue application. It’s not required to use single files components for Vue application, but they give you some advantages:

  • recommended style for Vue applications
  • modern components-based approach
  • good separation of concern between markup, css and code
  • we don’t need to use standalone version of Vue and can use runtime version, which is smaller
  • since we are using runtime version of Vue, our app works a bit faster, because not need to compile templates (already compiled by vue-loader)

Original sample can be founded under SharePoint Framework client-side web part samples – that’s a basic todo web part built with Vue. This a companion post describing some concepts.

The most difficult part is to setup our SPFx build pipeline to support Vue. Here are the steps required in order to make SPFx vue-compatible: More...

SharePoint Framework–extending build pipeline with custom configurations

Sometimes you need to adjust SPFx build pipeline a bit, in order to add your own webpack loaders or modify configuration for some tasks. This can be done in different ways depending on your needs. Let’s try to take a closer look at the options available.   Below is a diagram showing common config flow with extensibility points:


There are two places where you can put your customizations – under custom task’s config adjustments or using configuration file under config/[task name].json during loadCustomConfigs() method. More...

SharePoint development state in 2016: story based on sharepoint.stackexchange analysis with Power BI

I’ve heard about Power BI and Power BI Desktop a lot, but have never tried these tools before. So I decided to make an analysis of some popular  questions and answers forum - with help of Power BI Desktop. If you are SharePoint person (developer, admin, power user, etc.) that’s a big chance that you have visited this site before or may be you are even frequent visitor. In this post you will find a lot images, graphics, trends, tables, maps, charts and so on. All made with great tool Power BI Desktop and Stack Exchange API as data source. Some advanced data was collected with help of Google Maps Geocode API and nodejs webpages scrapper – osmosis.

The data was grabbed from sharepoint.stackexchange in the beginning of January, 2017. Most of the data is filtered starting from 2010 year, because relatively small number of questions were created before 2010 (around 200).

NOTA: all thoughts here are just my thoughts and may be incorrect or not aligned with yours. Please, share your opinion in comments.

Basic data

Let’s start with some basic information available:



SharePoint 2010 modal dialog extensions

Hi all. During digging into different sharepoint *.debug.js files I also investigating into sp.ui.dialog.debug.js. Out of the box modal dialog framework has some number of methods for manipulating dialog window, but some methods (that might be useful) missed. For example programmatically maximize or restore dialog window. Here is a couple of extension methods that I’ve created:

  • maximize -  maximizes modal dialog window
  • restore -  restores modal dialog window
  • toggleView – maximizes if modal dialog window is not maximized and vice versa
  • setSize – set size for modal dialog window (height, width in pixels)

Here is the code:

	SP.UI.ModalDialog.prototype.toggleView = function () {
	SP.UI.ModalDialog.prototype.maximize = function (){
	SP.UI.ModalDialog.prototype.restore = function (){
	SP.UI.ModalDialog.prototype.setSize = function (width, height){
		if(typeof width == "number" && typeof height == "number") {
			this.$Q_0(width, height);
}, "sp.ui.dialog.js");

Example of use:

var dlg = SP.UI.ModalDialog.get_childDialog();

Enjoy and good luck in spdevelopment.

SharePoint 2010 feature upgrade–upgrade pattern

Hi all! Today I’m going to show example of how to write clean and understandable code when using feature upgrade. Of course, solution which we are using is not perfect, but it rather solid, easy to use, easy to read, easy to extend. If you have any suggestions, improvements, or event better and cooler solution – you are welcome in comments :). Ok, lets start.

You are already know, that with sharepoint 2010 you can upgrade your features by adding this sample xml:

    <VersionRange BeginVersion="" EndVersion="">
      <CustomUpgradeAction Name="SomeActionName">
          <Parameter Name="TitlePrefix">Upgrade Time:</Parameter>

CustomUpgradeAction is not the only allowed tag inside VersionRange, but I’m going to focus on it, because with this tag we can specify actions, which invokes by code. To use above action you need to specify upgrade actions receiver and override FeatureUpgrading  method. Very straightforward and simple implementation of this method for our above example can looks like this one:

public override void FeatureUpgrading(SPFeatureReceiverProperties properties, string upgradeActionName, System.Collections.Generic.IDictionary<string, string> parameters)
	switch (upgradeActionName)
		case "SomeActionName":
			var web = properties.Feature.Parent as SPWeb;
			var list = web.Lists["TestUpgradeList"];
			var item = list.Items.Add();
			item["Title"] = parameters["TitlePrefix"] +  DateTime.Now.ToShortTimeString();
		case "AnotherAction":
			//do other stuff

Pretty cool, but what if you have 20-30 different actions? More...